CERT-RMM Reference

[SC:SG2.SP1] Identify the acquirer's high-value services

A fundamental risk management principle is to focus on activities to protect and sustain services and assets that most directly affect the acquirer's ability to achieve its mission. This practice refers to identifying the assessed acquirer's high-value services, which it provides to its customers and other stakeholders.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, The Fundamentals, 2.1 Multitiered Risk Management.

To integrate the risk management process throughout the organization and more effectively address mission/business concerns, a three-tiered approach is employed that addresses risk at the: (i) organizational level; (ii) mission/business process level; and (iii) information system level.

Tier 1 provides a prioritization of organizational missions/business functions which in turn drives investment strategies and funding decisions --promoting cost-effective, efficient information technology solutions consistent with the strategic goals and objectives of the organization and measures of performance.

NIST CSF References: ID.BE

CERT-RMM Reference

[SC:SG2.SP1] Identify the acquirer's high-value services

Prioritize and document the list of high-value services that must be provided if a disruption occurs. Consideration of the consequences of the loss of high-value acquirer services is typically performed as part of a business impact analysis. In addition, the consequences of risks to high-value services are identified and analyzed in risk assessment activities. The acquirer must consider this information when prioritizing high-value services.

Additional References

NIST Special Publication 800-34, “Contingency Planning for Federal Information Systems,”

3.2.3 Identify System Resource Recovery Priorities, 16-18.

Recovery priorities can be effectively established taking into consideration mission/business process criticality, outage impacts, tolerable downtime, and system resources. The result is an information system recovery priority hierarchy. The ISCP Coordinator should consider system recovery measures and technologies to meet the recovery priorities.

NIST CSF References: ID.AM-5, ID.BE

CERT-RMM Reference

[ADM:SG1.SP1] Inventory assets

An acquirer must be able to identify its high-value assets, document them, and establish their value. This is done in order to develop strategies for protecting and sustaining assets commensurate with their value to services. The term high-value assets refers both to assets that are internal to the assessed acquirer and those that are owned, maintained, provided, etc. by external entities.

Additional References

NIST Special Publication 800-18 Revision 1, “Guide for Developing Security Plans for Federal Information Systems,” 2-3.

NIST CSF References: ID.AM-1, ID.AM-2, ID.AM-4

CERT-RMM Reference

[CTRL:SG1.SP1] Define control objectives

Define and document control objectives that result from management directives and guidelines. Affinity analysis of directives and guidelines may be useful in identifying categories of control objectives.

These are examples of control objectives:

• prevent unauthorized use of purchase orders
• ensure adequate supplies of materials
• establish an enterprise architecture for information technology
• all outside support personnel are identified
• identify and assess risks that may cause material misstatements of financial records
• educate and train staff
• ensure the confidentiality and integrity of customers' payment information
• establish a compliance program

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, 2.1 Multitiered Risk Management.

The selection and specification of security controls for an information system is accomplished as part of an organization-wide information security program for the management of risk --that is, the risk to organizational operations and assets, individuals, other organizations, and the Nation associated with the operation of information systems. Risk-based approaches to security control selection and specification consider effectiveness, efficiency, and constraints due to applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidelines.

NIST CSF References: ID.BE-5, ID.GV-3

CERT-RMM Reference

[EXD:SG3.SP3] Evaluate and Select External Entities.

External entities should be selected according to an organized and thorough process and according to explicit specifications and selection criteria. The selection process and criteria should be designed to ensure that the selected entity can fully meet the acquirer's specifications.

NIST Reference

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-12 Supply Chain Protection.

Protection of organizational information systems is accomplished through threat awareness, by the identification, management, and reduction of vulnerabilities at each phase of the life cycle and the use of complementary, mutually reinforcing strategies to respond to risk. Organizations consider implementing a standardized process to address supply chain risk with respect to information systems and system components, and to educate the acquisition workforce on threats, risk, and required security controls.

Additional References

ITIL Service Strategy, The Stationery Office, 2011, Best Management Practice. Section 3.7, “Sourcing Strategy,” 117-125.

NIST CSF References: ID.BE-1, ID.SC-1, ID.SC-2, ID.SC-3

CERT-RMM Reference

[EXD:SG3.SP1] Establish Enterprise Specifications for External Dependencies

When external entities support the execution of the organization's services, they become an extension of the organization and should be subject to the same or similar policies, standards, and guidelines as the organization's staff. These enterprise level policies, standards and guidelines must be translated to a set of enterprise-level specifications and reflected in agreements with each external entity to ensure a seamless implementation of the organization's resilience strategy.

NIST Reference

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, The Fundamentals, 2.1.

Basic practices include ensuring that federal department and agency acquirers understand the cost and scheduling constraints of the practices, integrating information security requirements into the acquisition language, using applicable baseline security controls as one of the sources for security requirements, ensuring a robust software quality control process, and establishing multiple delivery routes for critical system elements.

Additional References

ISO 27036-3, “Information Technology - Security techniques-Information Security for Supplier Relationships,” Part 3, 6.1.1, 7.

NIST CSF References: ID.BE-1, ID.GV-3, ID.SC-3, PR.IP-5

CERT-RMM Reference

[EXD:SG3.SP2] Establish Resilience Specifications for External Entities.

For each external dependency, establish a list of resilience specifications that apply to the responsible external entity. The process for determining and documenting the resilience specifications that apply to an external dependency and entity will vary based on the action of the entity in relation to the acquirer's operations, the priority of the external dependency, and the management structure within the acquirer. At a minimum, the resilience specifications should include a clear and definitive statement of the external entity's services, support, products, assets, or staff on which the acquirer relies.

Requirements should be gathered and documented for each type of external dependency. Even in cases where it is not practical to include these requirements in formal agreements with external entities, they are useful as a way to assess and manage risks against external dependencies.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 3.2.3 Define/Develop Requirements

The acquirer mission/business owner or their designee, with assistance from the procurement official and other members of the SCRM team, if applicable, should define and document requirements for the procurement. During this process, mission, functionality, quality, and security requirements should be developed and documented. This process will identify the requirements for the procurement and how these requirements will apply to the specific items of supply (elements and processes).

ISO 27036-2, “IT-Security Techniques-Information Security for Supplier Relationships, ” Requirements Introduction.

NIST CSF References: ID.BE-1, ID.BE-5, ID.SC-3

CERT-RMM Reference

[EXD:SG3.SP3] Evaluate and Select External Entities

From a resilience perspective, the selection process for external entities is often an extension of or supplement to the organization's standard procurement processes. Resilience specifications may simply serve as additional requirements for consideration and evaluation as part of the standard procurement process. In all cases, due diligence should be performed on candidate external entities to evaluate their ability to meet the resilience specifications that have been established for the actions they hope to perform for the organization.

In some cases, external entities cannot be selected from a pool of candidates; they may be inherited in the course of an acquisition or merger or they may be the only provider of a high-value service on which the organization depends (this is often the case for public services). In cases in which external entities cannot be selected, the due diligence process for selection should still be performed to identify any specifications that are not met by the external entity. It may be appropriate to alter the specifications by changing the actions or nature of the dependence on the external entity to resolve the unmet specifications. In cases where the specifications cannot be changed, any unmet specifications should be treated as risks.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA12(2) Supply Chain Protection | Supplier Reviews.

The organization conducts a supplier review prior to entering into a contractual agreement to acquire the information system, system component, or information system service. Supplemental Guidance: Supplier reviews include, for example: (i) analysis of supplier processes used to design, develop, test, implement, verify, deliver, and support information systems, system components, and information system services; and (ii) assessment of supplier training and experience in developing systems, components, or services with the required security capability. These reviews provide organizations with increased levels of visibility into supplier activities during the system development life cycle to promote more effective supply chain risk management. Supplier reviews can also help to determine whether primary suppliers have security safeguards in place and a practice for vetting subordinate suppliers, for example, second- and third-tier suppliers, and any subcontractors.

ITIL Service Strategy, The Stationery Office, 2011, Best Management Practice. Section 3.7, “Sourcing Strategy,” 117-125.

NIST CSF References: ID.BE-1, ID.BE-4, ID.SC-3

CERT-RMM Reference

[RISK:SG1.SP2] Establish a Risk Management Strategy

Because of the pervasive nature of operational risk, a comprehensive operational risk management strategy is needed to ensure proper consideration of risk and the effects on operational resilience. The strategy provides a common foundation for the performance of operational risk management activities (which are typically dispersed throughout the organization) and for the collection, coordination, and elevation of operational risk to the organization's enterprise risk management process.

Preparation for operational risk management requires the organization to develop and maintain a strategy for identifying, analyzing, and mitigating operational risks. This strategy is documented in a risk management plan and addresses the activities that the organization performs enterprise-wide to carry out a continuous risk management program. This includes identifying the sources and types of operational risk and establishing a strategy that details the organization's approach, activities, and objectives for managing these risks as a fundamental operational resilience management process

Additional References

NIST Special Publication 800-39, “Managing Information Security Risk Acquirer, Mission, and Information System View,” 2.1 Components of Risk Management.

Managing risk is a complex, multifaceted activity that requires the involvement of the entire organization

--from senior leaders/executives providing the strategic vision and top-level goals and objectives for the organization; to mid-level leaders planning, executing, and managing projects; to individuals on the front lines operating the information systems supporting the organization's missions/business functions. Risk management is a comprehensive process that requires organizations to: (i) frame risk (i.e., establish the context for risk-based decisions); (ii) assess risk; (iii) respond to risk once determined; and (iv) monitor risk on an ongoing basis using effective organizational communications and a feedback loop for continuous improvement in the risk-related activities of organizations. Risk management is carried out as a holistic, organization-wide activity that addresses risk from the strategic level to the tactical level, ensuring that risk-based decision making is integrated into every aspect of the organization.

NIST CSF References: ID.GV-4, ID.RM-1, ID.SC-1

CERT-RMM References

[EXD:SG2.SP1] Identify Risks Due to External Dependencies.

Identification of risks due to external dependencies requires an understanding of the actions of the associated external entity in the operation, support, or resilience of the organization's services. External entities will be responsible for varying dependencies in the support of the organization's operations.

[RISK:SG1:SP1] Determine Risk Sources and Categories.

The sources of risk to assets and services are identified and the categories of risk that are relevant to the organization are determined.

Identifying risk sources helps the organization to determine and categorize the types of operational risk that are most likely to affect day-to-day operations and to seed an organization-specific risk taxonomy that can be used as a tool for managing risk on a continuous basis as operating conditions change and evolve. The sources of risk can be both internal and external to the organization.

Categorizing operational risks provides the organization a means from which to perform advanced analysis and mitigation activities that allow for similar types of risks to be effectively neutralized or contained by limited actions by the organization.

Additional References

NIST Special Publication 800-30, “Risk Management Guide for Information Technology Systems,” Section 2.4 Application of Risk Assessments.

ISO 28000 First Edition, “Specifications for security management systems for the supply Chain.”

NIST CSF References: ID.BE-1, ID.RA-5, ID.RA-6, ID.SC-1, ID.SC-2, ID.SC-4

CERT-RMM Reference

[EXD:SG1.SP2] Prioritize External Dependencies

Determine whether the loss of a single supplier will cause unacceptable disruption to critical services. This can be accomplished through affinity analysis. For this type of vendor, allow for service risks by clearly defining requirements and/or applicable mitigations, such as alternate vendors in the event of a failure from the primary vendor.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA12(13) Supply Chain Protection | Critical Information System Components.

Adversaries can attempt to impede organizational operations by disrupting the supply of critical information system components or corrupting supplier operations. Safeguards to ensure adequate supplies of critical information system components include, for example:

(i) the use of multiple suppliers throughout the supply chain for the identified critical components; and (ii) stockpiling of spare components to ensure operation during mission-critical times.

OCC Bulletin 2013-29. Subject: Third-Party Relationships United States Department of the Treasury, October 30, 2013.

Senior management should ensure that periodic independent reviews are conducted on the third-party risk management process, particularly when a bank involves third parties in critical activities. . . .

Reviews may include assessing the adequacy of the bank's process for

• identifying and managing concentration risks that may arise from relying on a single third party for multiple activities, or from geographic concentration of business due to either direct contracting or subcontracting agreements to the same locations.

ITIL Service Strategy, The Stationery Office, 2011, Best Management Practice. Section 3.7.3, “Multi- vendor Sourcing.”

NIST CSF References: ID.RA-4, ID.RA-5, ID.SC-2, ID.SC-4

CERT-RMM Reference

[EXD:SG3.SP3] Evaluate and Select External Entities.

External entities should be selected according to an organized and thorough process and according to explicit specifications and selection criteria. The selection process and criteria should be designed to ensure that the selected entity can fully meet the acquirer's specifications, which should be outlined in various work products. These products include requests for proposals, external entity selection criteria, evaluations of each external entity proposal against the selection criteria, and selection decision and supporting rationale documents.

Additional References

[CERT CMMI-ACQ, SSAD: SG1.SP2] Establish a Solicitation Package

Establish and maintain a solicitation package that includes the requirements and proposal evaluation criteria. Solicitation packages are used to seek proposals from potential suppliers. The acquirer structures the solicitation package to facilitate an accurate and complete response from each potential supplier and to enable an effective comparison and evaluation of proposals.

The solicitation package includes a description of the desired form of the response, the relevant statement of work for the supplier, and required provisions in the supplier agreement (e.g., a copy of the standard supplier agreement or non-disclosure provisions). In government acquisitions, some or all of the content and structure of the solicitation package can be defined by regulation.

The solicitation package is rigorous to ensure consistent and comparable responses but flexible enough to allow consideration of supplier suggestions for better ways to satisfy requirements.

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 3.2.5 Complete Procurement.

NIST CSF References: ID.SC-2, ID.SC-3

CERT-RMM Reference

[EXD:SG3.SP3] Evaluate and Select External Entities

External entities should be selected according to an organized and thorough process and according to explicit specifications and selection criteria. The selection process and criteria should be designed to ensure that the selected entity can fully meet the organization's specifications.

From a resilience perspective, the selection process for external entities is often an extension of or supplement to the organization's standard procurement processes. Resilience specifications may simply serve as additional requirements for consideration and evaluation as part of the standard procurement process. In all cases, due diligence should be performed on candidate external entities to evaluate their ability to meet the resilience specifications that have been established for the actions they hope to perform for the organization.

Additional References

NIST Special Publication 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations", SA-12(2) Supply Chain Protection | Supplier Reviews.

The organization conducts a supplier review prior to entering into a contractual agreement to acquire the information system, system component, or information system service.

Supplemental Guidance: Supplier reviews include, for example: (i) analysis of supplier processes used to design, develop, test, implement, verify, deliver, and support information systems, system components, and information system services; and (ii) assessment of supplier training and experience in developing systems, components, or services with the required security capability. These reviews provide organizations with increased levels of visibility into supplier activities during the system development life cycle to promote more effective supply chain risk management.

NIST Special Publication 800-39, “Managing Information Security Risk Acquirer, Mission, and Information System View," 24-26.

NIST CSF References: ID.BE-1, ID.BE-4, ID.SC-3

CERT-RMM Reference

[EXD:SG3.SP3] Evaluate and Select External Entities

Evaluate suppliers based on their abilities to meet the resilience specifications and in accordance with the established selection criteria. Due diligence should be performed on candidate external entities to validate their ability to meet the resilience specifications that have been established for the actions they hope to perform for the acquirer. Any specifications that are not being met by the external entity should be treated as risks and potentially be a factor in eliminating that supplier from consideration as an approved service provider.

Additional References

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Management Systems and Organizations,” 46.

A variety of methods may be used to communicate and subsequently verify and monitor ICT SCRM requirements through such vehicles as contracts, interagency agreements, lines of business arrangements, licensing agreements, and/or supply chain transactions. These methods include

• Clearly defining the types of external services provided to the external organization
• Describing how the external services should be protected in accordance with the federal agency ICT supply chain security requirements; and

Obtaining the necessary verifications that the risk to the organizations' organizational operations and assets, individuals, other organizations, and the Nation arising from the use of the external services is acceptable.

NIST CSF References: ID.SC-2, ID.SC-3

CERT-RMM Reference

[EXD:SG3.SP3] Evaluate and Select External Entities

External entities should be selected according to an organized and thorough process and according to explicit specifications and selection criteria. The selection process and criteria should be designed to ensure that the selected entity can fully meet the organization's specifications.

[EXD:SG3.SP2] Establish Resilience Specifications for External Entities.

Resilience specification should include specific characteristics that are required such as degree of reliance on other external entities.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA12(2) Supply Chain Protection| Supplier Reviews.

Supplier reviews can also help to determine whether primary suppliers have security safeguards in place and practice for vetting subordinate suppliers, for example, second and third-tier suppliers, and any subcontractors

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Management Systems and Organizations,” Sections 3.3.1 and 3.3.2.

System integrators are those entities that provide customized services to the acquirer including custom development, test, operations, and maintenance. This group usually replies to a request for proposal from an acquirer with a proposal that describes solutions or services that are customized to the acquirer's requirements. Such proposals provided by system integrators can include many layers of suppliers (see Chapter 3.3.2). The system integrator should ensure that those suppliers are vetted and verified with respect to the acquirer's ICT SCRM requirements. Because of the level of visibility that can be obtained in the relationship with the system integrator, the acquirer has the ability to require rigorous supplier acceptance criteria as well as any relevant countermeasures to address identified or potential risks.

Organizations should consider that the costs of doing business with suppliers may be directly impacted by the level of visibility the suppliers allow into how they apply security and supply chain practices to their solutions. When organizations or system integrators require greater levels of transparency from suppliers, they must consider the possible cost implications of such requirements. Suppliers may select to not participate in procurements to avoid increased costs or perceived risks to their intellectual property, limiting an organization's supply or technology choices. The risk to suppliers is the potential for multiple, different sets of requirements that they may have to individually comply with, which may not be scalable.

Board of Governors of the Federal Reserve System, December 5, 2013. “Guidance on Managing Outsourcing Risk,” 4-6.

NIST CSF References: ID.SC-2, ID.SC-3

CERT-RMM Reference

[EXD:SG3.SP4] Formalize Relationships

Agreements are often composed from multiple sections or multiple documents, each of which describes some aspect of the arrangement and agreement. In all cases, the agreement, regardless of form, should:

• be enforceable by the organization
• include detailed and complete specifications that must be met by the external entity (see EXD:SG3.SP1 and EXD:SG3.SP2)
• include any required performance standards or work products from the organization
• be changed to reflect changes in specifications over the life of the relationship

Subpractices:

1. Select an agreement type that best fits the performance standards required by the organization and that is enforceable if problems arise.
2. Properly document the agreement terms, conditions, specifications and other provisions. All agreement provisions should be documented in the agreement in language that is unambiguous.

The agreement should not contain any general exceptions for achieving the resilience specifications unless they are carefully considered and negotiated. It may, however, contain scenarios of types of unforeseen events for which the external entity is not expected to prepare. Any exceptions granted to resilience specifications or scenarios for which the external entity is not required to prepare should be treated as risks under EXD:SG2.

All agreements should establish and enable procedures for monitoring the performance of external entities and inspecting the services or products they deliver to the organization.

Additional References

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Management Systems and Organizations,” Section 1.5 Foundational Practices.

Foundational practices are described in NIST standards and guidelines as well as other applicable national and international standards and best practices. They include: ensuring that organizations understand the cost and scheduling constraints of implementing ICT SCRM; integrating information security requirements into the acquisition process; using applicable baseline security controls as one of the sources for security requirements.

ISO 27036-2, “IT-Security Techniques-Information Security for Supplier Relationships,” Section 6.1 Agreement Processes.

ISO 27036-1, “IT-Security Techniques-Information Security for Supplier Relationships,” Section 5.5 ICT Supply Chain Considerations.

NIST CSF References: ID.BE-1, ID.SC-3, PR.AT-3

CERT-RMM References

[EXD:SG3.SP4] Formalize Relationships

Formal agreements should be established with external entities. The agreement content may take different forms depending on subcontracting provisions - The external entity's rights and ability to subcontract their obligations under the agreement to others should be included.

[EXD:GG2.GP4] Assign Responsibility

Assign responsibility and authority for performing the external dependencies management process, developing the work products, and providing the services of the process.

Those responsible for services and assets are involved in identifying and prioritizing external dependencies and establishing resilience specifications that external entities must fulfill. Formal agreements identify external entity actions, including ensuring continuity of operations during times of stress.

Subpractices:

1. Assign responsibility and authority for performing the process.

The organization must ensure that responsibility and authority extends to all external entities and to any entities with whom the external entity has contracted to provide services or products in support of the external entity's formal agreement with the organization.

Additional References

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Management Systems and Organizations,” Sections 3.3.1 and 3.3.2.

System integrators are those entities that provide customized services to the acquirer including custom development, test, operations, and maintenance. Because of the level of visibility that can be obtained in the relationship with the system integrator, the acquirer has the ability to require rigorous supplier acceptance criteria as well as any relevant countermeasures to address identified or potential risks.

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems”, Section 4.7.1 Acquirer - Programmatic Activities.

9. Require the integrator to monitor supplier activities, with notification to supplier, to detect and assess threats or attempts to gain, or exploit exposure of, access to elements, supply chain processes, or supply chain actors.
10. Require that reviewers are qualified to identify weaknesses and vulnerabilities in the supply chain or integrator SCRM processes and procedures.

ISO 27036-1, “IT-Security Techniques-Information Security for Supplier Relationships,” 5.3 Information Security Risks in Supplier Relationships and Associated Threats.

NIST CSF References: ID.SC-3

CERT-RMM References

[EXD:SG3.SP4] Formalize Relationships

Supplier agreement should define obligations of the external entity to protect the acquirer's assets and report material incidents that have the potential to impact those assets. Those obligations should include requirements for the notification of the acquirer in the event of disruptions and security incidents such as breaches and disclosures.

[IMC:GG2.GP4] Assign Responsibility

Assign responsibility and authority for performing the incident management and control process, developing the work products, and providing the services of the process.

Specific practice IMC:SG1.SP1 indicates that the incident management plan should define the roles and responsibilities necessary to carry out the plan, as well as documenting commitments from those responsible.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations", SA-12(12) | Inter-Organizational Agreements, SA-12(13) Supply Chain Protection | Critical Information System Components.

The organization establishes inter-organizational agreements and procedures with entities involved in the supply chain for the information system, system component, or information system service.

Supplemental Guidance: The establishment of inter-organizational agreements and procedures provides for notification of supply chain compromises. Early notification of supply chain compromises that can potentially adversely affect or have adversely affected organizational information systems, including critical system components, is essential for organizations to provide appropriate responses to such incidents.

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Management Systems and Organizations,” Section 2.5 Foundational Practices.

NIST CSF References: ID.SC-3

CERT-RMM References

[EXD:SG3.SP2] Establish Resilience Specifications for External Dependencies

Consider the following topics when establishing required behaviors and standards of performance for external dependencies and entities:

• security, including incident management procedures and performance, vulnerability and penetration management, logical and physical access controls, identity management, and security standards compliance.

[VAR:GG2.GP4] Assign Responsibility

Assign responsibility and authority for performing the specific tasks of the process, including by

• developing and implementing contractual instruments (including service level agreements) with external entities to establish responsibility and authority for performing process tasks on outsourced functions.

Additional References

ISO 27036-1, “IT-Security Techniques-Information Security for Supplier Relationships,” 5.5 ICT Supply Chain Considerations, 5.3 Information Security Risks in Supplier Relationships and Associated Threats.

NIST CSF References: ID.SC-3

CERT-RMM References

[IMC:GG2.GP4] Assign Responsibility

Assign responsibility and authority for performing the incident management and control process, developing the work products, and providing the services of the process.

Subpractices

1. Assign responsibility and authority for performing the process.
2. Assign responsibility and authority for performing the specific tasks of the process such as: developing and implementing contractual instruments (including service level agreements) with external entities to establish responsibility and authority for performing process tasks on outsourced functions, assets, and services.

[SC:GG2.GP4] Assign Responsibility

Assign responsibility and authority for performing the service continuity process, developing the work products, and providing the services of the process.

Subpractices

1. Assign responsibility and authority for performing the process.

2. Assign responsibility and authority for performing the specific tasks of the process, such as: developing and implementing contractual instruments (including service level agreements) with external entities to establish responsibility and authority for performing process tasks on outsourced functions.

Additional References

ISO 22301 First Edition, “Societal Security - Business continuity management systems - Requirements.”

NIST CSF References: ID.SC-3

CERT-RMM References

[IMC:GG2.GP7] Identify and Involve Relevant Stakeholders

Assign responsibility and authority for performing the incident management and control process, developing the work products, and providing the services of the process.

Stakeholders (including external entities) may be involved in various tasks in the incident management and control process, such as

• detecting events and incidents
• planning for incident handling, management, and response
• making commitments to process plans and activities
• collecting, documenting, and preserving event and incident evidence
• analyzing events and incidents
• declaring incidents
• responding to incidents, including participating on incident response teams
• communicating events and incidents and the status of incidents as they move through the incident life cycle
• escalating incidents
• coordinating process activities
• reviewing and appraising the effectiveness of process activities
• performing post-incident review and improvement processes

[SC:GG2.GP4] Assign Responsibility

Assign responsibility and authority for performing the service continuity process, developing the work products, and providing the services of the process.

Subpractices

1. Assign responsibility and authority for performing the process.
2. Assign responsibility and authority for performing the specific tasks of the process, such as: developing and implementing contractual instruments (including service level agreements) with external entities to establish responsibility and authority for performing process tasks on outsourced functions.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, CP-4 Contingency Plan Testing.

The organization coordinates contingency plan testing with organizational elements responsible for related plans.

Supplemental Guidance: Plans related to contingency plans for organizational information systems include, for example, Business Continuity Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, Cyber Incident Response Plans, and Occupant Emergency Plans. This control enhancement does not require organizations to create organizational elements to handle related plans or to align such elements with specific plans. It does require, however, that if such organizational elements are responsible for related plans, organizations should coordinate with those elements. Related controls: IR-8, PM-8.

Federal Financial Institutions Examination Council (FFIEC) Business Continuity Planning IT Examination Handbook, Testing Strategies, 16.

The testing policy should include enterprise-wide testing strategies that establish expectations for individual business lines. Business lines include all internal and external supporting functions, such as IT and facilities management. The testing strategy should include the following:

• Expectations for business lines and support functions to demonstrate the achievement of business continuity test objectives consistent with the BIA and risk assessment;
• Expectations for testing internal and external interdependencies; and

ITIL Service Design, The Stationery Office, 2011, Best Management Practice. Section 4.8.5.5. “Sourcing Structures,” 219-220.

NIST CSF References: ID.SC-3, ID.SC-5

CERT-RMM Reference

[TM:SG2.SP1] Assign Resilience Requirements to Technology Assets

Resilience requirements that have been defined are assigned to technology assets.

Resilience requirements form the basis for the actions that the organization takes to protect and sustain technology assets. These requirements are established commensurate with the value of the asset to services that it supports. The resilience requirements for technology assets must be assigned to the assets so that the appropriate type and level of protective controls can be designed, implemented, and monitored to meet the requirements.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 3.2.3 Define/Develop Requirements.

The acquirer mission/business owner or their designee, with assistance from the procurement official and other members of the SCRM team, if applicable, should define and document requirements for the procurement. During this process, mission, functionality, quality, and security requirements should be developed and documented. This process will identify the requirements for the procurement and how these requirements will apply to the specific items of supply (elements and processes).

NIST Special Publication 800-39, “Managing Information Security Risk Acquirer, Mission, and Information System View,” 24-26.

ISO 27036-2, “IT-Security Techniques-Information Security for Supplier Relationships,” Requirements Introduction.

NIST CSF References: ID.BE-5

CERT-RMM References

[VAR: SG2.SP2] Discover vulnerabilities

Data collection should be coordinated to discover vulnerabilities and populate the vulnerability repository as efficiently as possible.

[VAR: SG3.SP1] Manage Exposure to Vulnerabilities

Develop a vulnerability management strategy for all vulnerabilities that require resolution. The strategy should address the actions that the organization will take to reduce or eliminate exposure or to provide an operational workaround if preferable. This includes ensuring that relevant stakeholders are informed of resolution activities.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-12(2) Supply Chain Protection | Supplier Reviews.

The organization conducts a supplier review prior to entering into a contractual agreement to acquire the information system, system component, or information system service.

Supplemental Guidance: Supplier reviews include, for example: (i) analysis of supplier processes used to design, develop, test, implement, verify, deliver, and support information systems, system components, and information system services; and (ii) assessment of supplier training and experience in developing systems, components, or services with the required security capability. These reviews provide organizations with increased levels of visibility into supplier activities during the system development life cycle to promote more effective supply chain risk management. Supplier reviews can also help to determine whether primary suppliers have security safeguards in place and a practice for vetting subordinate suppliers, for example, second- and third-tier suppliers, and any subcontractors.

Protection of organizational information systems is accomplished through threat awareness, by the identification, management, and reduction of vulnerabilities at each phase of the life cycle and the use of complementary, mutually reinforcing strategies to respond to risk. Organizations consider implementing a standardized process to address supply chain risk with respect to information systems and system components, and to educate the acquisition workforce on threats, risk, and required security controls.

NIST Special Publication 800-40 Version 3.0, “Creating a Patch Management and Vulnerability Management Program.” 2.3.2 Monitoring Vulnerabilities, Remediations, and Threats, 7.

Vendors are the authoritative source of information for patches related to their products. However, many vendors will not announce vulnerabilities in their products until patches are available; accordingly, monitoring third-party vulnerability resources as well is recommended.

ISO 27036-3, “Information technology - Security techniques - Information Security for Supplier Relationships” Part 3, 6.

NIST CSF References: ID.BE-4, ID.RA-1

CERT-RMM Reference

[EXD:SG3.SP1] Establish Enterprise Specifications for External Dependencies

Enterprise specifications that apply in general to external entities are established and maintained.

The organization has a set of values and behaviors that it follows when carrying out its operation. These values and behaviors may be derived to support the organization's strategy or designed to create or reinforce the organization's public image. They may also be a reflection of the organization's market sector or the function of regulations or other constraints to which the organization must comply.

Regardless of the source, the organization's values and behaviors should be reflected in high-level organizational policies that govern the behavior of staff and external entities whenever they are representing or performing services for the organization.

[EXD:SG3.SP3] Evaluate and Select External Entities

The ability for an external organization to predictably meet specifications.

The specifics of establishing and maintaining trust can differ from organization to organization based on mission/business requirements, the participants involved in the trust relationship, the criticality/sensitivity of the information being shared or the types of services being rendered, the history between the organizations, and the overall risk to the organizations participating in the relationship.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations", SA-13 Trustworthiness.

• Describes the trustworthiness required in the information system, information system component, or information system service supporting its critical missions/ business functions;

Supplemental Guidance: This control helps organizations to make explicit trustworthiness decisions when designing, developing, and implementing information systems that are needed to conduct critical organizational missions/business functions. Trustworthiness is a characteristic/property of an information system that expresses the degree to which the system can be expected to preserve the confidentiality, integrity, and availability of the information it processes, stores, or transmits. Trustworthy information systems are systems that are capable of being trusted to operate within defined levels of risk despite the environmental disruptions, human errors, and purposeful attacks that are expected to occur in the specified environments of operation. Trustworthy systems are important to mission/business success.

Two factors affecting the trustworthiness of information systems include: (i) security functionality (i.e., the security features, functions, and/or mechanisms employed within the system and its environment of operation); and (ii) security assurance (i.e., the grounds for confidence that the security functionality is effective in its application).

NIST Special Publication 800-39, “Managing Information Security Risk Acquirer, Mission, and Information System View,” 24-26.

ISO 20243, "Information Technology -- Open Trusted Technology Provider Standard (O- TTPS) -- Mitigating maliciously tainted and counterfeit products," 1.2 Overview.

The Open Trusted Technology Provider Standard (O-TTPS) is a set of guidelines, requirements, and recommendations that, when practically applied, create a business benefit in terms of reduced risk of acquiring maliciously tainted or counterfeit products for the technology acquirer.

Trusted Technology Providers manage their product life cycle, including their extended supply chains, through the application of defined, monitored, and validated best practices. The product's integrity is strengthened when providers and suppliers follow (. . .) requirements and recommendations (that have been) taken from the experience of mature industry providers, rigorously reviewed (. . .), and established as requirements and recommendations . . .

The Open Trusted Technology Provider Standard is available for download at: www.opengroup.org

NIST CSF References: ID.SC-2

CERT-RMM References

[TM:SG3.SP2] Mitigate Technology Risk

Risk mitigation strategies for technology assets are developed and implemented.

The mitigation of technology asset risk involves the development of strategies that seek to minimize the risk to an acceptable level. This includes reducing the likelihood of risks to technology assets, minimizing exposure to these risks

[TM:GG2.GP2] Plan the Technology Management Process

Establish and maintain the plan for performing the technology management process.

A plan for performing the technology management process is created to preserve the integrity of technology assets and to ensure that technology assets remain available and viable to support organizational services. The plan must address the resilience requirements of the technology assets, dependencies of services on these assets, and consideration of multiple asset owners and custodians at various levels of the organization.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, Section 2.5 External Suppliers.

The degree of confidence that the risk from using external services is at an acceptable level depends on the trust that organizations place in external service providers. In some cases, the level of trust is based on the amount of direct control organizations are able to exert on external service providers with regard to employment of security controls necessary for the protection of the service/information and the evidence brought forth as to the effectiveness of those controls. The level of control is usually established by the terms and conditions of the contracts or service- level agreements with the external service providers and can range from extensive control (e.g., negotiating contracts or agreements that specify detailed security requirements for the providers) to very limited control (e.g., using contracts or service-level agreements to obtain commodity services such as commercial telecommunications services).

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-13 Trustworthiness.

• Describes the trustworthiness required in the information system, information system component, or information system service] supporting its critical missions/ business functions;

Supplemental Guidance: This control helps organizations to make explicit trustworthiness decisions when designing, developing, and implementing information systems that are needed to conduct critical organizational missions/business functions. Trustworthiness is a characteristic/property of an information system that expresses the degree to which the system can be expected to preserve the confidentiality, integrity, and availability of the information it processes, stores, or transmits. Trustworthy information systems are systems that are capable of being trusted to operate within defined levels of risk despite the environmental disruptions, human errors, and purposeful attacks that are expected to occur in the specified environments of operation. Trustworthy systems are important to mission/business success.

Two factors affecting the trustworthiness of information systems include: (i) security functionality (i.e., the security features, functions, and/or mechanisms employed within the system and its environment of operation); and (ii) security assurance (i.e., the grounds for confidence that the security functionality is effective in its application).

NIST Special Publication 800-39, “Managing Information Security Risk Acquirer, Mission, and Information System View,” 24-26.

ISO 20243, "Information Technology -- Open Trusted Technology Provider Standard (O- TTPS) -- Mitigating maliciously tainted and counterfeit products," 1.2 Overview.

ISO 27036-1, “IT-Security Techniques-Information Security for Supplier Relationships,” 5.1 Business case for ICT Supply Chain Security.

NIST CSF References: ID.SC-2

CERT-RMM Reference

[TM:SG2.SP2] Establish and Implement Controls

Administrative, technical, and physical controls that are required to meet the established resilience requirements are identified and implemented.

The organization must implement an internal control system that protects the continued operation of technology assets commensurate with their role in supporting organizational services. Controls are essentially the methods, policies, and procedures that the organization uses to provide an acceptable level of protection over high-value technology assets. Controls typically fall into three categories: administrative (or managerial), technical, and physical. All of these controls are necessary for technology assets because they come in so many different forms and are pervasive across the organization.

Subpractices include: Establish and specify controls over the design, construction, or acquisition of technology assets. These controls ensure that the development and acquisition of software and systems or the development and acquisition of hardware is performed with consideration of the operational resilience of these assets.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-12(10) Supply Chain Protection | Validate as Genuine and Not Altered.

The organization employs security safeguards to validate that the information system or system component received is genuine and has not been altered.

Supplemental Guidance: For some information system components, especially hardware, there are technical means to help determine if the components are genuine or have been altered.

Security safeguards used to validate the authenticity of information systems and information system components include, for example, optical/nanotechnology tagging and side-channel analysis. For hardware, detailed bill of material information can highlight the elements with embedded logic complete with component and production location.

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Management Systems and Organizations,” Sections 3.3.1 and 3.3.2.

System integrators are those entities that provide customized services to the acquirer including custom development, test, operations, and maintenance. This group usually replies to a request for proposal from an acquirer with a proposal that describes solution or services that are customized to the acquirer's requirements. Such proposals provided by system integrators can include many layers of suppliers (see Chapter 3.3.2). The system integrator should ensure that those suppliers are vetted and verified with respect to the acquirer's ICT SCRM requirements. Because of the level of visibility that can be obtained in the relationship with the system integrator, the acquirer has the ability to require rigorous supplier acceptance criteria as well as any relevant countermeasures to address identified or potential risks.

NIST Special Publication 800-39, “Managing Information Security Risk Acquirer, Mission, and Information System View,” 24-26.

NIST CSF References: ID.SC-2, PR.IP-2

CERT-RMM Reference

[EXD:SG1.SP1] Identify External Dependencies

It is important for the organization to identify and characterize external dependencies so that they can be understood, formalized, monitored, and managed as part of the organization's comprehensive risk management process.

The organization's list of services should be examined to discover services that may be subject to external dependencies, in whole or in part. The organization's inventory of assets should also be examined to discover assets that are under the control of external entities or are in other ways subject to external dependencies. The organization may find value and efficiency in establishing close service links or overlap to facilitate information sharing between the external dependencies list, the services listing, and the asset inventory. The organization's customer database and supplier database may also be valuable sources of insight when establishing the catalog of external dependencies. The organization's set of current supplier and vendor contracts and related service level agreements (SLAs) are additional sources.

When the organization is establishing the catalog of external dependencies, its customer database and supplier database may also be valuable sources of insight. The organization's set of current supplier and vendor contracts and related service level agreements (SLAs) are additional sources.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 4.1, Uniquely Identify Supply Chain Elements, Processes, and Actors.

Knowing who and what is in an enterprise's supply chain is critical to gaining visibility into what is happening within it, as well as monitoring and identifying high-risk events and activities. Without reasonable visibility and traceability into the supply chain, e.g., elements, processes, and actors, it is impossible to understand and therefore manage risk, and to reduce the likelihood of an adverse event.

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section 2-0 Criticality Analysis.

Update Criticality Analysis of mission-critical functions, systems, and components to narrow the scope (and resources) for ICT SCRM activities to those most important to mission success.

Criticality analysis should include the ICT supply chain infrastructure for both the organization and applicable system integrators, suppliers, external service providers, and the systems/components/ services. Criticality analysis assesses the direct impact they each have on the mission priorities.

In addition to updating and tailoring Baseline Criticality, performing criticality analysis in the Assess Step may include the following:

• Obtain and review existing information that the agency has about critical ICT systems/ components, such as locations where they are manufactured or developed, physical and logical delivery paths, information flows and financial transactions associated with these components, and any other available information that can provide insights into ICT supply chain of these components

Additional Reference

ITIL Service Design, The Stationery Office, 2011, Best Management Practice. 4.8.7 “Information Management,” 224.

NIST CSF References: ID.BE-4, ID.SC-2

CERT-RMM Reference

[EXD:SG1.SP2] Prioritize External Dependencies

Apply the acquirer's prioritization criteria to the list of external dependencies to produce a prioritized list. Depending on the prioritization scheme developed by an organization, the result might be several lists, tiers, or sets of external dependencies. Be sure that external dependencies that are required for the successful execution of security activities, service continuity plans, and service restoration plans are prioritized appropriately.

Additional References

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section 2.2.1 Frame.

As a part of identifying ICT supply chain Risk Assumptions within the broader Risk Management process (described in NIST SP 800-39), agencies should do the following:

• Define ICT SCRM mission, business, and system-level requirements;
• Identify which mission functions and related components are critical to the organization, including FIPS 199 impact level, to determine the baseline criticality;

NIST CSF References: ID.BE-4, ID.SC-2

CERT-RMM Reference

[EXD:SG1.SP1] Identify External Dependencies

The organization may use any number of techniques to establish a catalog or detailed list of external dependencies.

The purpose of the catalog of external dependencies is to support the identification and prioritization of external dependencies and the management of risks associated with selected dependencies.

The organization's external dependencies will change over time as a result of changes to relationships with essential suppliers and customers, changes in services, the life cycle of assets, and many other reasons. Once the list of external dependencies is established, it is important that it be maintained. A process for updating the list on a regular basis should be established.

Additional References

NIST CSF References: ID.BE-4, ID.SC-2

CERT-RMM References

[RRM:SG1.SP3] Manage Resilience Requirements Changes. Changes to resilience requirements are managed as conditions dictate.

The conditions under which organizations operate are continually changing. As a result, the risk environment for services and associated assets continues to evolve as well. An organization must become very adept at recognizing changes in conditions that (dictate or may require) changes in asset resilience requirements.

Managing changes to requirements involves consideration of several distinct activities:

• identifying change triggers and criteria including: changes that result in outsourcing services and assets or in changing current external entity relationships

[EXD:SG3.SP2] Establish Resilience Specifications for External Dependencies

Periodically review and update resilience specifications for external dependencies and entities as conditions warrant.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 3.2.1 Operational Contract Execution.

Once a system becomes operational, the operating environment may change. Changes involve, but are not limited to, suppliers, elements, delivery processes, and business processes. These changes may alter, add, or reduce ICT supply chain risks. During operations, acquirers should continue to perform ICT SCRM, including the assessment of foundational enterprise practices. The acquirer will need to ensure that the integrator or supplier understands supply chain risk and provides information on applicable changes to the elements, environment, vulnerabilities, and patches on an ongoing basis. The following activities will help the acquirer maintain supply chain oversight and improve processes for future procurements:

Monitor and periodically (or continuously if appropriate) reevaluate changes in the risk environment that impact the supply chain including technology innovation, operational environment, regulatory environment, etc. Respond to change where appropriate through modifying ICT SCRM requirements.

ISO 27036-2, “IT-Security Techniques-Information Security for Supplier Relationships, ” 7.4.3 Supplier relationship agreement process - Activities.

ISO 27036-3, “IT-Security Techniques-Information Security for Supplier Relationships,” 6.4.2e.

NIST CSF: References: ID.BE-1, ID.BE-5, ID.SC-3

CERT-RMM Reference

[EXD:SG2.SP1] Identify and Assess Risks Due to External Dependencies

Risks associated with external dependencies are periodically identified and assessed.

Risks due to external dependencies must be identified and assessed so that they can be effectively managed to maintain the resilience of the organization's high-value services.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 4.1, Uniquely Identify Supply Chain Elements, Processes, and Actors.

Knowing who and what is in an enterprise's supply chain is critical to gain visibility into what is happening within it, as well as monitoring and identifying high-risk events and activities. Without reasonable visibility and traceability into supply chain, e.g., elements, processes, and actors, it is impossible to understand and therefore manage risk, and to reduce the likelihood of an adverse event.

ITIL Service Design, The Stationery Office, 2011, Best Management Practice. Section 4.8.5.4, “Establishment of New Suppliers and Contracts,” 218-219.

ISO 27036-1, “IT-Security Techniques-Information Security for Supplier Relationships,” 5.3 Information Security Risks in Supplier Relationships and Associated Threats.

ISO 27036-2, “IT-Security Techniques-Information Security for Supplier Relationships,” Section 6.3.4 Risk Management Process.

NIST CSF References: ID.SC-1, ID.SC-4

CERT-RMM References

[EXD:GG2.GP7] Identify and Involve Relevant Stakeholders

Identify and involve the relevant stakeholders of the external dependencies management process as planned.

Identify process stakeholders and their appropriate involvement. Because external entities may reside in a wide range of physical locations and provide and support numerous processes, services, and assets, a substantial number of stakeholders are likely to be external to the organization.

These are examples of stakeholders of the plan for the external dependencies management process:

• internal and external owners and custodians of organizational assets
• internal and external service owners
• organizational unit and line of business managers responsible for high-value assets and the services they support
• staff responsible for managing operational risks arising from external dependencies and relationships with external entities
• staff responsible for establishing, implementing, and maintaining an internal controls system for organizational assets, where an external entity is involved
• staff required to develop, test, implement, and execute service continuity plans that involve external dependencies and external entities
• acquisition and procurement staff
• internal and external auditors

[RISK:GG2.GP8] Monitor and Control the Process

Monitor and control the risk management process against the plan for performing the process and take appropriate corrective action.

Additional References

NIST Special Publication 800-161, ”Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section AC-21 Collaboration and Information Sharing.

Sharing information within the ICT supply chain can help to manage ICT supply chain risks. This information may include vulnerabilities, threats, criticality of systems and components, or delivery information. This information sharing should be carefully managed to ensure that the information is accessible only to authorized individuals within the organization's ICT supply chain.

ISO 27036-1, “IT-Security Techniques-Information Security for Supplier Relationships”, 5.3 Information Security Risks in Supplier Relationships and Associated Threats.

ITIL Service Design, The Stationery Office, 2011, Best Management Practice. Section 4.8.5.4, “Establishment of New Suppliers and Contracts,” 218-219.

NIST CSF References: ID.SC-2, ID.SC-4

CERT-RMM References

[VAR GG2.GP7] Identify and Involve Relevant Stakeholders

Identify process stakeholders and their appropriate involvement. These are examples of stakeholders of the vulnerability analysis and resolution process:

• higher level managers responsible for establishing organizational risk criteria and tolerances
• staff responsible for the organization's risk management plan
• asset owners, custodians, and users
• staff responsible for managing operational risks to assets
• staff responsible for establishing, implementing, and maintaining an internal control system for assets
• staff responsible for developing, testing, implementing, and executing service continuity plans
• external entities responsible for managing high-value assets and providing essential services
• internet service providers
• legal counsel
• information technology staff, such as system administrators and CSIRTs
• staff responsible for physical security (for facility assets)
• owners of operational resilience management processes, including risk management, incident management and control, and service continuity

[VAR GG2.GP8] Monitor and Control the Process

Monitor and control the process against the plan for performing the process and take appropriate corrective action. The process should include high-value information, technology, and facilities assets (including assets owned and managed by external entities as well as internally).

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management for Federal Information Systems,”4.7 Perform Continuous Integrator Review.

Continuous integrator review is an essential practice used to ascertain that defensive measures have been deployed. It includes testing, monitoring, auditing, assessments, and any other means by which the acquirer observes integrator practices. The purpose of continuous integrator review is to validate compliance with requirements, ascertain that the system behaves in a predictable manner under stress, and detect and classify weaknesses and vulnerabilities of elements, processes, systems, and any associated metadata.

NIST CSF References: ID.RA-1, ID.SC-4, PR.IP-12, DE.CM-8, RS.AN-5, RS.MI-3

CERT-RMM References

[RISK:SG5.SP2] Implement Risk Strategies

Risk strategies and mitigation plans are implemented and monitored.

[EXD:SG3.SP3] Evaluate and Select External Entities.

In some cases, external entities cannot be selected from a pool of candidates; they may be inherited in the course of an acquisition or merger, or they may be the only provider of a high-value service on which the organization depends (this is often the case for public services). In cases in which external entities cannot be selected, the due diligence process for selection should still be performed to identify any specifications that are not met by the external entity. It may be appropriate to alter the specifications by changing the actions or nature of the dependence on the external entity to resolve the unmet specifications. In cases where the specifications cannot be changed, any unmet specifications should be treated as risks.

Additional References

NIST CSF References: ID.RM-1, ID.SC-1, ID.SC-2, ID.SC-4

CERT-RMM References

[RISK:SG5.SP2] Implement Risk Strategies

Risk strategies and mitigation plans are implemented and monitored.

Effective management and control of risk requires the organization to monitor risk and the status of risk strategies. Because the operational environment is constantly changing, risks identified and addressed may need to be revisited, and a new disposition and strategy may need to be developed.

[EXD:SG4.SP1] Monitor External Entity Performance

The performance of external entity relationship management and governance is monitored against agreement terms and specifications. Utilization of a repository to store external dependency information facilitates the management of the overall external dependencies management program and the relationship management and governance process, in particular.

Typical work products

1. Monitoring of reports on external entities
2. Relationship management databases showing current performance monitoring information
3. Inspection reports on external entity deliverables

Subpractices

1. Establish procedures and responsibility for monitoring external entity performance and inspecting any external entity deliverables. Procedures should be consistent with the agreement between the organization and the external entity and should be based on verifying that the external entity is achieving the specifications as defined in the agreement.

2. Meet periodically with external entity representatives to review the result of monitoring activities, the specifications in the agreement, and any changes in either the organization or the external entity that might impact performance

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-12(11) Supply Chain Protection | Penetration Testing / Analysis of Elements, Processes, and Actors.

The organization employs . . . organizational analysis, independent third- party analysis, organizational penetration testing, independent third-party penetration testing of supply chain elements, processes, and actors associated with the information system, system component, or information system service.

Supplemental Guidance: This control enhancement addresses analysis and/or testing of the supply chain, not just delivered items. Supply chain elements are information technology products or product components that contain programmable logic and that are critically important to information system functions. Supply chain processes include, for example: (i) hardware, software, and firmware development processes; (ii) shipping/ handling procedures; (iii) personnel and physical security programs; (iv) configuration management tools/measures to maintain provenance; or (v) any other programs, processes, or procedures associated with the production/distribution of supply chain elements. Supply chain actors are individuals with specific roles and responsibilities in the supply chain. The evidence generated during analyses and testing of supply chain elements, processes, and actors is documented and used to inform organizational risk management activities and decisions.

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations.”

NIST CSF References: ID.RM-1, ID.SC-1, ID.SC-2, ID.SC-4

CERT-RMM Reference

[EXD:SG4.SP1] Monitor External Entity Performance

The performance of external entities is monitored against resilience requirements and agreement terms and specifications. Using an information repository to store external entity information facilitates management of external entity performance and requirements.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 4.7 Perform Continuous Integrator Review.

Acquirers should use the continuous integrator review to help determine if integrators are fulfilling the requirements defined in the agreement and whether any remedial actions are required based on the environment and use.

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” Section 3.3 Implement a Continuous Monitoring Program.

NIST CSF References: ID.SC-4, PR.IP-5, DE.CM-6

CERT-RMM References

[EXD:GG2.GP7] Identify and Involve Relevant Stakeholders.

Identify and involve the relevant stakeholders of the external dependencies management process as planned.

Subpractices

1. Identify process stakeholders and their appropriate involvement.
2. Communicate the list of stakeholders to planners and those responsible for performance of the process.
3. Involve relevant stakeholders in the process as planned.

[EXD:SG4.SP1] Monitor External Entity Performance

To ensure that performance monitoring is performed on a timely and consistent basis, the organization should establish procedures that determine the frequency, protocol, and responsibility for monitoring a particular external entity. (Responsibility is typically assigned to the organizational owner of the relationship.) These procedures should be consistent with the terms of the agreement with the external entity. It may be appropriate to adjust the monitoring frequency in response to changes in the risk environment, changes to external dependencies, or changes in the external entity.

Typical work products

1. Monitoring of reports on external entities
2. Relationship management databases showing current performance monitoring information
3. Inspection reports on external entity deliverables

Additional References

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section 3 TASK 3-2: Evaluate Alternative Courses of Action for Responding to Risk.

To tailor a set of ICT SCRM controls, the organization should perform ICT SCRM and mission-level trade-off analysis to achieve appropriate balance among ICT SCRM and functionality needs of the organization. This analysis will result in a set of cost-effective ICT SCRM controls that is dynamically updated to ensure that mission-related considerations trigger updates to ICT SCRM controls.

During this evaluation, applicable requirements and constraints are reviewed with the stakeholders to ensure that ICT SCRM controls appropriately balance ICT SCRM and the broader organizational requirements, such as cost, schedule, performance, policy, and compliance.

NIST CSF References: ID.SC-1, ID.SC-4

CERT-RMM Reference

[EXD:SG4.SP2] Correct External Entity Performance

The agreement should be reviewed to identify appropriate and allowable corrective actions for consideration. The various alternatives should be evaluated based on their likelihood to succeed in correcting the situation and mitigating any associated risks. It may be valuable and appropriate to include the external entity in the discussion and consideration of alternatives, especially if both the organization and the external entity desire to continue the relationship.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 4.1.6 Acquirer - Verification and Validation Activities.

Perform audits on unique . . . deficiencies within acquirer system/environment and report up the supply chain for corrective action.

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-12(15) Supply Chain Protection | Processes to Address Weaknesses or Deficiencies.

The organization establishes a process to address weaknesses or deficiencies in supply chain elements identified during independent or organizational assessments of such elements.

Supplemental Guidance: Evidence generated during independent or organizational assessments of supply chain elements (e.g., penetration testing, audits, verification/ validation activities) is documented and used in follow-on processes implemented by organizations to respond to the risks related to the identified weaknesses and deficiencies. Supply chain elements include, for example, supplier development processes and supplier distribution systems.

ISO 27036-2,“IT-Security Techniques-Information Security for Supplier Relationships,” 7.4.3 Activities.

NIST CSF References: ID.SC-4

CERT-RMM Reference

[EXD:SG4.SP2] Correct External Entity Performance

Implementing corrective actions is a necessary part of managing external entity performance. The objective of any corrective action is to minimize the disruption to the organization's operation or the risk of any such disruption based on external dependencies. The range of corrective actions should be established in the agreement with the external entity, and an evaluation of alternatives should be completed prior to implementing corrective actions.

Corrective actions should be documented in accordance with specifications in the agreement and used to inform and improve ongoing monitoring of the external entity.

Typical work products

• Corrective action reports or documentation
• Correspondence with an external entity documenting corrective actions

Subpractices

1. Evaluate alternative corrective actions to select the optimal corrective action.
2. The agreement should be reviewed to identify appropriate and allowable corrective actions for consideration. The various alternatives should be evaluated based on their likelihood to succeed in correcting the situation and mitigating any associated risks.
3. It may be valuable and appropriate to include the external entity in the discussion and consideration of alternatives, especially if both the organization and the external entity desire to continue the relationship.
4. Communicate with the external entity to review selected corrective actions.
5. Communication provisions in the agreement should be followed to formalize the communication.
6. Implement selected corrective actions.
7. Monitor as appropriate to ensure that issues are remedied in a timely manner.
8. Update the agreement with the external entity as required.

Additional References

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” Section 3.5 Respond to Findings.

Response strategies may be implemented over a period of time, documenting implementation plans in the system's Plan of Action and Milestones (POA&M). As weaknesses are found, response actions are evaluated and any mitigation actions are conducted immediately or are added to the POA&M. Other key system documents are updated accordingly. Security controls that are modified, enhanced, or added as part of the response step of the continuous monitoring process are assessed to ensure that the new or revised controls are effective in their implementations. Going forward, new or revised controls are included in the overall continuous monitoring strategy.

NIST Special Publication 800-55, “Performance Measurement Guide for Information Security.”

NIST CSF References: ID.SC-4

CERT-RMM Reference

[ADM:SG3.SP2] Manage Changes to Assets and Inventory

Organizational and operational conditions are continually changing. These changes result in daily changes to the high-value assets that help the organization's services achieve their missions. For example, the following are common organizational events that would affect high-value assets:

• staff changes, including the addition of new staff members (either internally or externally), the transfer of existing staff members from one organizational unit to another, and the termination of staff members
• changes to information such as the creation, alteration, or deletion of paper and electronic records, files, and databases
• technology refresh, such as the addition of new technical components, changes to existing technical components, and the elimination or retirement of existing technology
• facilities changes, such as the addition of new facilities (whether owned by the organization or an external business partner), alteration of existing facilities, and the retirement of a facility

Besides the addition of new assets, this practice also addresses changes to the description or composition of an asset. For example, if an asset takes an additional form (such as when a paper asset is imaged or an electronic asset is printed), this must be documented as part of the asset description to ensure that current protection and sustainment strategies align properly and provide coverage across a range of asset media. Assets may also change ownership, custodianship, location, or value --all of which must be updated to ensure a current asset profile and inventory.

In addition, whenever assets are eliminated (for example, a server is retired or vital staff members leave the organization), owners of those assets must ensure that their resilience requirements are either eliminated (if possible) or are transferred and updated to the assets that replace them. Doing this is especially critical when assets are shared between services and have common resilience requirements.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, CM-3 Configuration Change Control

1. Determines the types of changes to the information system that are configuration- controlled;
2. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses;
3. Documents configuration change decisions associated with the information system;
4. Implements approved configuration-controlled changes to the information system;
5. Retains records of configuration-controlled changes to the information system
6. Audits and reviews activities associated with configuration-controlled changes to the information system; and
7. Coordinates and provides oversight for configuration change control activities

ITIL Service Transition, The Stationery Office, 2011, Best Management Practice. Section 4.2, “Change Management.”

NIST CSF References: PR.IP

CERT-RMM Reference

[ADM:GG2.GP7] Involve Relevant Stakeholders

Changes to assets are managed as conditions dictate. Organizational and operational conditions are continually changing. These changes result in daily changes to the high-value assets that help the organization's services achieve their missions.

Subpractices

1. Identify process stakeholders and their appropriate involvement. Elaboration:

These are examples of stakeholders of the asset definition and management process:

• asset owners and custodians
• service owners
• organizational unit and line of business managers responsible for high-value assets and the services they support
• staff responsible for establishing, implementing, and maintaining an internal control system for assets
• external entities responsible for managing high-value assets
• information technology staff (for technology assets)
• staff responsible for physical security (for facility assets)

Stakeholders are involved in various tasks in the asset definition and management process, such as

• planning for the process
• creating an asset inventory baseline
• creating asset profiles
• associating assets with services and analyzing asset-service dependencies
• managing changes to assets and to the asset inventory
• reviewing and appraising the effectiveness of process activities
• resolving issues in the process

[EXD:SG3.SP4] Formalize Relationships

When external entities support the execution of the acquirer's services, they become an extension of the acquirer and should be subject to the same or similar policies, standards, and guidelines as the acquirer's employees. Change procedures should be part of a formal agreement that is established with an external entity. The change procedures should also include procedures for changing any of the agreement provisions by mutual agreement.

Defining and communicating change procedures, including both routine and emergency changes, ensures that changes to assets will be handled in an efficient and controlled manner, consistent with acquirer policy, standards, and guidelines.

The acquirer should ensure that the external entities understand the acquirer's service priorities. When sourcing services, the acquirer should clearly define what the external entity is expected to do, including ensuring that the external entity is trained on the acquirer's processes and procedures. The acquirer and the external entity should work collaboratively to integrate their respective change processes and procedures to ensure that changes to assets are managed.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-12 Supply Chain Protection.

ITIL Service Transition, The Stationery Office, 2011, Best Management Practice. Section 4.2.6.4, “Interfaces.”

NIST CSF References: PR.IP-3, PR.MA-1, PR.MA-2

CERT-RMM Reference

[EXD:SG3.SP4] Formalize Relationships

When external entities support the execution of the acquirer's services, they become an extension of the acquirer and should be subject to the same or similar policies, standards, and guidelines as the acquirer's employees.

Change procedures should be part of a formal agreement that is established with an external entity. The change procedures should also include procedures for changing any of the agreement provisions by mutual agreement. Defining and communicating change procedures, including both routine and emergency changes, ensures that changes to assets will be handled in an efficient and controlled manner, consistent with acquirer policy, standards, and guidelines.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 4.1.1 Integrators - Verification and Validation Requirements.

Use multiple and complementary monitoring and auditing approaches and leverage existing data to analyze for supply chain risk during sustainment.

Evaluate the changes in maintenance agreements (e.g., physical move to different location/ offshoring, changes in ownership, outsourcing, and change in key personnel) and manage risks associated with them.

ISO 27036-1, “IT-Security Techniques-Information Security for Supplier Relationships,” 5.5C ICT Supply Chain Considerations.

ITIL Service Design, The Stationery Office, 2011, Best Management Practice. Section 4.8.5, “Process Activities, Methods and Techniques.”

NIST CSF References: ID.SC-1, ID.SC-3, ID.SC-4

CERT-RMM References

[MON:SG1.SP1] Establish Monitoring Program

Establish and maintain the program for identifying, collecting, and distributing monitoring information.

[EXD:SG4.SP1] Monitor External Entity Performance

The performance of external entities is monitored to ensure against specifications, including:

• controls and control environments
• financial condition and management practices of the external entity
• service continuity and incident management plans
• compliance practices and performance

[CTRL:SG4.SP1] Assess Controls

Assessing the control system at external entities is an ongoing activity that allows the acquirer to measure the effectiveness of controls across resilience activities. For example, through monitoring and ongoing measurement and analysis, the acquirer can determine whether controls at external entities are satisfying control objectives, strategies for protecting and sustaining services and assets, and resilience requirements. These activities can also ascertain if controls for resilience activities are effective and producing the intended results. Monitoring and measurement are two ways that the acquirer collects necessary data (and invokes a vital feedback loop) to know how well controls are performing in support of the operational resilience of high value services.

NIST Reference

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-12(8) Supply Chain Protection | Use of All Source Intelligence.

ISO 27036-2, “IT-Security Techniques-Information Security for Supplier Relationships,”7.4.3 Supplier Relationship Agreement Process - Activities.

NIST CSF References: ID.SC-1, ID.SC-4, DE.CM-6

CERT-RMM Reference

[TM:SG5.SP3] Manage Technology Capacity

Capacity is a significant factor in meeting the availability requirements of technology assets and, in turn, of the services that rely on these assets.

Consideration of capacity to ensure technology availability and meet business objectives requires a proactive approach to managing demand and anticipating future needs. Capacity management should be part of a formal agreement that is established with an external entity. Defining and communicating a capacity management strategy and the related requirements helps ensure that assets will meet the resilience requirements of the service.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 4.4 Share Information within Strict Limits.

Acquirers, integrators, and suppliers need to share data and information. For the purposes of ICT SCRM, information sharing is the process by which acquirers, integrators, and suppliers (including COTS) exchange pertinent data and information. The data and information that may be shared can span the entire system or element life cycle and the entire supply chain. Content to be shared may include data and information about the use of elements, users, acquirer, integrator, or supplier organizations, as well as information regarding issues that have been identified or raised regarding specific elements. Information should be protected according to mutually agreed-upon practices.

ITIL Service Transition, The Stationery Office, 2011, Best Management Practice. Section 4.2.6.4, “Interfaces.”

NIST CSF References: ID.SC-3, ID.SC-4, PR.DS-4

CERT-RMM Reference

[EXD:SG4.SP2] Correct External Entity Performance

Corrective actions are implemented to support external entity performance as necessary.

Implementing corrective actions is a necessary part of managing external entity performance. The objective of any corrective action is to minimize the disruption to the organization's operation or the risk of any such disruption based on external dependencies. The range of corrective actions should be established in the agreement with the external entity, and an evaluation of alternatives should be completed prior to implementing corrective actions.

Additional References

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” Section 3.5 Respond to Findings.

Response strategies may be implemented over a period of time, documenting implementation plans in the system's Plan of Action and Milestones (POA&M). As weaknesses are found, response actions are evaluated and any mitigation actions are conducted immediately or are added to the POA&M.

ITIL Service Design, The Stationery Office, 2011, Best Management Practice. Section 4.8.5.6, “Contract Renewal or Termination.”

NIST CSF References: ID.SC-1, ID.SC-3, PR.IP-2

CERT-RMM Reference

[EXD:GG2.GP1] Establish Process Governance

Establish and maintain governance over the planning and performance of the external dependencies management process. Governance over the external dependencies may include:

• providing guidance on identifying, assessing, and managing operational risks related to external dependencies;
• verifying that the process supports strategic resilience objectives and is focused on the assets and services that are of the highest relative value in meeting strategic objectives.

Additional References

NIST Special Publication 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations", SA-12(13) Supply Chain Protection | Critical Information System Components.”

Adversaries can attempt to impede organizational operations by disrupting the supply of critical information system components or corrupting supplier operations. Safeguards to ensure adequate supplies of critical information system components include, for example: (i) the use of multiple suppliers throughout the supply chain for the identified critical components; and (ii) stockpiling of spare components to ensure operation during mission-critical times.

OCC Bulletin 2013-29. Subject: Third-Party Relationships United States Department of the Treasury, October 30, 2013, section: Risk Management Lifecycle, Termination.

(. . . ) Developing a contingency plan to ensure that the bank can transition the activities to another third party, bring the activities in-house, or discontinue the activities when a contract expires, the terms of the contract have been satisfied, in response to contract default, or in response to changes to the bank's or third party's business strategy. In addition, a bank should perform the following throughout the life cycle of the relationship as part of its risk management process:

• Oversight and accountability: Assigning clear roles and responsibilities for managing third-party relationships and integrating the bank's third-party risk management process with its enterprise risk management framework enables continuous oversight and accountability.
• Documentation and reporting: Proper documentation and reporting facilitates oversight, accountability, monitoring, and risk management associated with third-party relationships.
• Independent reviews: Conducting periodic independent reviews of the risk management process management to assess whether the process aligns with the bank's strategy and effectively manages risk posed by third-party relationships.

ITIL Service Design, The Stationery Office, 2011, Best Management Practice. Section 4.8.5.6, “Contract Renewal or Termination.”

ITIL Service Strategy, The Stationery Office, 2011, Best Management Practice. Section 3.7.3, “Multi- vendor Sourcing.”

NIST CSF References: ID.SC-1, ID.SC-3

CERT-RMM Reference

[EXD:GG3.GP2] Collect Improvement Information

Collect external dependencies work products, measures, measurement results, and improvement information derived from planning and performing the process to support the future use and improvement of the organization's processes and process assets.

[EXD:SG4.SP2] Correct External Entity Performance

Corrective actions should be documented in accordance with specifications in the agreement and used to inform and improve ongoing monitoring of the external entity.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section 4.1.1.e Integrators - Acquirer Programmatic Activities.

Define processes by which general supply chain information and lessons learned will be collected and shared between acquirers, integrators, and suppliers as scoped within the contract. Define how this information should be protected based on acquirer, integrator, and supplier agreements.

NIST CSF References: ID.SC-1, PR.IP-7, PR.IP-8

CERT-RMM References

[EXD:SG3.SP2] Establish Resilience Specifications for External Dependencies

Periodically review and update resilience specifications for external dependencies and entities as conditions warrant.

[EC:SG4.SP4] Manage Dependencies on Public Infrastructure

Identify and document infrastructure dependencies that the organization relies upon to provide services. Remember that these dependencies may be internal as well as external, particularly where the organization has control over certain aspects of facility infrastructure, such as power or telecommunications that they provide for their own operations.

Typically, this activity results from business impact analysis. However, it can be included as part of service continuity planning or facility asset definition, depending on the organization. A resulting list of public infrastructure providers for each facility should be documented and made available for inclusion in service continuity plans as appropriate.

Additional References:

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section 3 TASK 4-2: Risk Monitoring.

Monitor organizational information systems and environments of operation on an ongoing basis to verify compliance, determine effectiveness of risk response measures, and identify changes.

. . . organizations should monitor compliance, effectiveness, and change. Monitoring compliance within the context of ICT SCRM involves monitoring an organization's processes and ICT products and services for compliance with the established security and ICT SCRM requirements. Monitoring effectiveness involves monitoring the resulting risks to determine whether these established security and ICT SCRM requirements produce the intended results. Monitoring change involves monitoring the environment for any changes that would require changing requirements and mitigations/controls to maintain an acceptable level of ICT supply chain risk.

ISO 27036-3, “IT-Security Techniques-Information Security for Supplier Relationships,” 6.4.2e. NIST CSF

References: ID.BE-1, ID.BE-5, ID.SC-3

CERT-RMM Reference

[EXD:SG4.SP1] Monitor External Entity Performance

Establish procedures and responsibility for monitoring external entity performance and inspecting any external entity deliverables....All agreement specifications should be considered for monitoring; it may be appropriate to prioritize monitoring and inspection activities based on a risk analysis of the specifications. Monitoring and inspection procedures should address the external entity's required characteristics, required behaviors, and required performance parameters.

The acquirer should have a process to track the organizational owner of the external entity relationship (i.e., the department and/or person in the organization who is responsible for the relationship with the external entity).

Additional References

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” Section 3.3 Implement a Continuous Monitoring Program.

NIST CSF References: ID.AM-6, ID.GV-2, ID.SC-4

CERT-RMM References

[EXD:GG2.GP7] Identify and Involve Relevant Stakeholders

Identify and involve the relevant stakeholders of the external dependencies management process as planned.

Subpractices

Identify process stakeholders and their appropriate involvement.

Because external entities may reside in a wide range of physical locations and provide and support numerous processes, services, and assets, a substantial number of stakeholders are likely to be external to the organization.

These are examples of stakeholders of the plan for the external dependencies management process:

• internal and external owners and custodians of organizational assets
• internal and external service owners
• organizational unit and line of business managers responsible for high-value assets and the services they support
• staff responsible for managing operational risks arising from external dependencies and relationships with external entities
• staff responsible for establishing, implementing, and maintaining an internal controls system for organizational assets where an external dependency and an external entity is involved
• staff required to develop, test, implement, and execute service continuity plans that involve external dependencies and external entities
• acquisition and procurement staff
• internal and external auditors

[EC:SG4.SG3] Manage dependencies on public services

Public services generally include services that are specific to the geographical region. Public services include

• fire response and rescue services
• local and, in some cases, federal law enforcement (police, National Guard, FBI, etc.)
• emergency management services, including paramedics and first responders

Additional References

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” Section 3.3 Implement a Continuous Monitoring Program.

NIST CSF References: ID.AM-6, ID.GV-2, ID.SC-4

CERT-RMM Reference

[EXD:GG2.GP7] Identify and Involve Relevant Stakeholders

Identify and involve the relevant stakeholders of the external dependencies management process as planned.

Subpractices:

Identify process stakeholders and their appropriate involvement.

Because external entities may reside in a wide range of physical locations and provide and support numerous processes, services, and assets, a substantial number of stakeholders are likely to be external to the organization.

These are examples of stakeholders of the plan for the external dependencies management process:

• internal and external owners and custodians of organizational assets
• internal and external service owners
• organizational unit and line of business managers responsible for high-value assets and the services they support
• staff responsible for managing operational risks arising from external dependencies and relationships with external entities
• staff responsible for establishing, implementing, and maintaining an internal controls system for organizational assets where an external dependency and an external entity is involved
• staff required to develop, test, implement, and execute service continuity plans that involve external dependencies and external entities
• acquisition and procurement staff
• internal and external auditors

Additional References

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” Section 3.3 Implement a Continuous Monitoring Program.

Part of the implementation stage of the continuous monitoring process is effectively organizing and delivering ISCM data to stakeholders in accordance with decision-making requirements. Tools and methodologies are chosen for the organization-wide ISCM architecture, in order to help ensure that risk- based decisions are informed by accurate, current security-related information.

NIST 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section AC-21 Collaboration and Information Sharing.

Organizations should clearly define boundaries for information sharing with respect to temporal, informational, contractual, security, access, system, and other requirements. Organizations should monitor and review for unintentional or intentional information sharing within its ICT supply chain activities including information sharing with system integrators, suppliers, and external service providers.

NIST CSF References: ID.SC-4

CERT-RMM Reference

[RISK:SG5.SP2] Implement Risk Strategies

Risk strategies and mitigation plans are implemented and monitored.

Effective management and control of risk requires the organization to monitor risk and the status of risk strategies. Because the operational environment is constantly changing, risks identified and addressed may need to be revisited, and a new disposition and strategy may need to be developed.

NIST Reference

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations.”

NIST CSF References: ID.RM-1, ID.SC-1

CERT-RMM Reference

[AM:SG1.SP1] Enable Access

Access privileges are assigned and approved by asset owners based on the role of the person, object, or entity that is requesting access. Asset owners are the persons or organizational units, internal or external to the organization, who have primary responsibility for the viability, productivity, and resilience of a high-value organizational asset. It is the owner's responsibility to ensure that requirements for protecting and sustaining assets are defined for assets under their control. In part, these requirements are satisfied by defining and assigning access privileges that are commensurate with the requirements. Therefore, the asset owner is responsible for granting and revoking access privileges to an identity based on the identity's role and the asset's resilience requirements. To be successful, asset owners must be aware of identities that need access to their assets and must evaluate the need with respect to business and resilience requirements before granting approval.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, AC-17 Remote Access

The organization:

1. Establishes and documents usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and
2. Authorizes remote access to the information system prior to allowing such connections.

ISO 27036-3, “IT-Security Techniques-Information Security for Supplier Relationships,” 6.2.2 Infrastructure Management Process.

NIST CSF References: PR.AC-1, PR.AC-2, PR.AC-3, PR.AC-6, PR.AC-7, PR.MA-2

CERT-RMM Reference

[AM:SG1.SP2] Manage Changes to Access Privileges

The continual evolution of the operational environment and the identity community (persons, objects, and entities) requires constant changes to be made to access privileges to organizational assets. There are many different scenarios that may result in legitimate changes to access privileges, such as

• changes in job responsibilities and roles, such as when employees are promoted, take other positions in the organization, or leave the organization
• changes to outsourcing arrangements or the roles of external contractors
• changes to internal and external systems and processes that access organizational assets
• changes in the identity community (i.e., addition or deletion of identity, changes to the identity's roles) (Changes to the identity community are addressed in ID:SG2.SP1 in the Identity Management process area.)
• changes to the assets to which access privileges are provided and/or changes to the asset's resilience requirements (which could cascade through all access privileges)
• periodic review and maintenance of access privileges (as described in AM:SG2.SP3)
• In order to get a handle on this ever-changing environment, the organization must establish criteria to determine when a change in the operational environment would trigger a change in access privileges.

Owners of organizational assets have a role in the change management of access privileges. Owners are responsible for initiating and approving changes as required before corresponding access controls are modified to accommodate the changes. This may involve communication between asset owners and asset custodians who are responsible for implementing and maintaining those access controls. Owners are also responsible for following up to ensure that access privileges have been granted only to the approved limit.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, AC-2, Account Management.

1. Identifies and selects the following types of information system(s)
2. Assigns account managers for information system accounts;
3. Establishes conditions for group and role membership;
4. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;
5. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;
6. Creates, enables, modifies, disables, and removes information system accounts in accordance with organization-defined procedures or conditions;
7. Monitors the use of information system accounts;
8. Notifies account managers:
   1. When accounts are no longer required;
   2. When users are terminated or transferred; and
   3. When individual information system usage or need-to-know changes;
9. Authorizes access to the information system based on:
   1. A valid access authorization;
   2. Intended system usage; and
   3. Other attributes as required by the organization or associated missions/business functions;
10. Reviews accounts for compliance with account management requirements and
11. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 4.2 Limit Access and Exposure within the Supply Chain.

NIST CSF References: PR.AC-1, PR.AC-2, PR.AC-3, PR.IP-11

CERT-RMM Reference

[AM:SG1.SP3] Periodically Review and Maintain Access Privileges

Establish regular review cycle and process. The mismanagement of access privileges is a major source of potential risks and vulnerabilities to the organization. Because assets and the identity community that needs access to the assets are pervasive across the organization, and in some cases extend beyond the organization, the ability to ensure that only authorized identities have appropriate privileges is an ongoing challenge. The organization must establish responsibility for regular review of access privileges and a process for correcting inconsistencies. The review cycle should consider the potential risks of excessive privileges as input to the time interval for performing regular review. Where access privileges provide rights (such as “superusers”), the review cycle may need to be more frequent.

1. Perform periodic review of access privileges by asset. Periodic review of access rights is the responsibility of the owners of organizational assets. Reviews should be performed in accordance with the time intervals determined in AM:SG1.SP3, Subpractice 1. In addition to identifying inconsistencies and misalignment, periodic review should also be performed to reaffirm the current need for access privileges.

2. Identify inconsistencies or misalignment in access privileges. Asset owners should document any inconsistencies or misalignment in access privileges. Owners should identify privileges that are:

• excessive
• out of alignment with the identity's role or job responsibility
• assigned but never approved by the asset owner
• in violation of the asset's resilience requirements

Owners should also identify identities that may have been provisioned with access privileges but are no longer considered as valid identities. A disposition for each inconsistency or misalignment should be documented, as well as the actions that need to be taken to correct these issues.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 4.2 Limit Access and Exposure within the Supply Chain.

NIST CSF References: PR.AC-1, PR.AC-2, PR.AC-3, PR.AC-4

CERT-RMM Reference

[IMC:SG2.SP1] Detect and Report Events

Events are detected and reported. The monitoring, identification, and reporting of events is the foundation for incident identification and commences the incident life cycle. Events potentially affect the productivity of organizational assets and, in turn, associated services. These events must be captured and analyzed so that the organization can determine if the event will become (or has become) an incident that requires organizational action. The extent to which an organization can identify events improves its ability to manage and control incidents and their potential effects.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, AC-2(12) Account Management | Account Monitoring / Atypical Usage.

(b) Reports atypical usage of information system accounts to (appropriate staff).

Supplemental Guidance: Atypical usage includes, for example, accessing information systems at certain times of the day and from locations that are not consistent with the normal usage patterns of individuals working in organizations.

NIST CSF References: PR.AC-1, PR.AC-2, PR.AC-3, PR.MA-2

CERT-RMM Reference

[IMC:SG1.SP1] Plan for Incident Management

Establish the incident management plan. The incident management plan should address, at a minimum

• the acquirer's philosophy for incident management
• the structure of the incident management process
• the requirements and objectives of the incident management process relative to managing operational resilience
• a description of how the acquirer will identify incidents, analyze them, and respond to them
• the roles and responsibilities necessary to carry out the plan
• applicable training needs and requirements

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, IR-4 Incident Handling.

1. Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery;
2. Coordinates incident handling activities with contingency planning activities; and
3. Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting A. changes accordingly.

NIST Special Publication 800-61, “Computer Security Incident Handling Guide,” Handbook for Computer Security Incident Response Teams (CSIRTs).

NIST CSF References: ID.SC-5, PR.IP-9

CERT-RMM References

[IMC:SG3.SP1] Define and Maintain Incident Declaration Criteria

Each organization has many unique factors that must be considered in determining when to declare an incident. Through experience, an organization may have a baseline set of events that define standard incidents, such as a virus outbreak, unauthorized access to a user account, or a denial-of-service attack. However, in reality, incident declaration may occur on an event-by-event basis.

To guide the organization in determining when to declare an incident (particularly if incident declaration is not immediately apparent), the organization must define incident declaration criteria.

[IMC:GG2.GP7] Involve Stakeholders

Stakeholders for the incident management and control process may extend across the organization and externally to business partners and vendors.

Additional References

NIST 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section AC-21 Collaboration and Information Sharing.

Sharing information within the ICT supply chain can help to manage ICT supply chain risks. This information may include vulnerabilities, threats, criticality of systems and components, or delivery information. This information sharing should be carefully managed to ensure that the information is accessible only to authorized individuals within the organization's ICT supply chain.

NIST Special Publication 800-61, “Computer Security Incident Handling Guide,” Section 3.3.1 Choosing a Containment Strategy.

NIST CSF References: DE.AE-5

CERT-RMM Reference

[SC:SG3.SP2] Develop and document Service Continuity Plans

Document the service continuity plans using available templates as appropriate. A service continuity plan typically includes the following information:

• identification of authority for initiating and executing the plan (plan ownership)
• identification of the communication mechanism to initiate execution of the plan

Additional References

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,,” Section 3 Contingency Planning, 74.

Organizations must establish, maintain, and effectively implement plans for emergency response, backup operations, and post-disaster recovery for organizational information systems to ensure the availability of critical information resources and continuity of operations in emergency situations.

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, CP-2(1) Contingency Plan | Coordinate with Related Plans.

NIST Special Publication 800-34, “Contingency Planning for Federal Information Systems,” Chapter 3.

ISO 22301, “Societal Security - Business continuity management systems - Requirements,” Section 6 Planning.

NIST CSF References: ID.SC-5, PR.IP-9

CERT-RMM References

[EXD:SG2.SP2] Mitigate Risks Due to External Dependencies

The mitigation of risk due to external dependencies involves the development of strategies that seek to minimize the risk to an acceptable level. This includes reducing the likelihood of risks, minimizing exposure to them, developing service continuity plans, and developing recovery and restoration plans to address the consequences of realized risk.

[SC:SG3.SP2] Develop and Document Service Continuity Plans

The organization or its assigned representatives develop required service continuity plans. The service owner typically develops service continuity plans, but this may vary. Sub- practices that apply to the involvement and consideration of external entities include identification of

• vital staff roles and responsibilities
• high-value technology assets needed to support the plan
• high-value information assets and vital records necessary to support the plan
• high-value facilities necessary to support the plan
• coordination activities required
• levels of authority at external entities

Additional References

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section 3 Contingency Planning, 74.

ICT supply chain concerns of contingency planning include planning for alternative suppliers of system components, alternative suppliers of systems and services, denial of service attacks to the supply chain, and planning for alternate delivery routes for critical system components. Additionally, many techniques used for contingency planning, such as alternative processing sites, have their own ICT supply chains including their own specific ICT supply chain risks. Organizations should ensure that they understand and manage ICT supply chain risks and dependencies related to the contingency planning activities as necessary.

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” Section 2.2 Foundational Practices.

Ensure that a robust incident management program is in place to successfully identify, respond to, and mitigate security incidents. This program should be capable of identifying causes of security incidents, including those originating from the supply chain.

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section 3 Contingency Planning, 74.

ICT supply chain concerns of contingency planning include planning for alternative suppliers of system components, alternative suppliers of systems and services, denial of service attacks to the supply chain, and planning for alternate delivery routes for critical system components. Additionally, many techniques used for contingency planning, such as alternative processing sites, have their own ICT supply chains including their own specific ICT supply chain risks. Organizations should ensure that they understand and manage ICT supply chain risks and dependencies related to the contingency planning activities as necessary.

NIST Special Publication 800-34, “Contingency Planning for Federal Information Systems,” Chapter 3.

NIST CSF References: ID.SC-2, ID.SC-5, PR.IP-9

CERT-RMM References

[IMC:GG2.GP7] Identify and Involve Relevant Stakeholders

Stakeholders of the incident management and service continuity processes may extend across the organization and externally to business partners and vendors. These can include external entities involved in process activities and responsible for managing high-value assets.

[SC:SG2.SP2] Identify Internal and External Dependencies and Interdependencies

Services depend on organizational assets, both internal and external, to ensure continuity of operations. They also rely on external partnerships such as public agencies and infrastructure such as public utilities and telecommunications. These dependencies and interdependencies must be identified in order to ensure a robust consideration of the range of planning that must be incorporated into the service continuity plans.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, CP-4(1) Contingency Plan Testing | Coordinate with Related Plans.

The organization coordinates contingency plan testing with organizational elements responsible for related plans.

Supplemental Guidance: Plans related to contingency plans for organizational information systems include, for example, Business Continuity Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, Cyber Incident Response Plans, and Occupant Emergency Plans. This control enhancement does not require organizations to create organizational elements to handle related plans or to align such elements with specific plans. It does require, however, that if such organizational elements are responsible for related plans, organizations should coordinate with those elements.

NIST 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section AC-21 Collaboration and Information Sharing.

NIST Special Publication 800-34, “Contingency Planning for Federal Information Systems,” Chapter 3.5 Plan Testing, Training, and Exercises (TT&E).

ISO 22301, “Societal Security - Business continuity management systems - Requirements,” Sections 6 and 7.

NIST CSF References: ID.SC-5, PR.IP-9

CERT-RMM References

[SC:SG5.SP3] Exercise Plans

Test the service continuity plan. On a regular basis, service continuity plans are exercised (tested) according to their test plan. Tests should include the participation of external entities where appropriate. The test should establish the viability, accuracy, and completeness of the plan. It should also provide information about the acquirer's level of preparedness to address the specific area(s) included in the plan.

[IMC:GG2.GP7] Identify and Involve Relevant Stakeholders

Stakeholders for the incident management and control process may extend across the organization and externally to business partners and vendors.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, CP-4(1) Contingency Plan Testing | Coordinate with Related Plans.

The organization coordinates contingency plan testing with organizational elements responsible for related plans.

Supplemental Guidance: Plans related to contingency plans for organizational information systems include, for example, Business Continuity Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, Cyber Incident Response Plans, and Occupant Emergency Plans.

NIST Special Publication 800-84, “Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities,” 6-1 to 6-6.

NIST Special Publication 800-61, “Computer Security Incident Handling Guide,” Section 3.2.3 Procedural Elements.

ISO 22301, “Societal Security - Business continuity management systems - Requirements,” Section 6 Planning and Section 8.5 Exercising and Testing.

NIST CSF References: ID.SC-4, ID.SC-5

CERT-RMM References

[SC:SG7.SP1] Establish Change Criteria

Because of changing operational and acquirer conditions, service continuity and incident management plans may have a short useful life. Identifying and understanding the types of acquirer and operational triggers that may indicate a need to revisit and revise service continuity plans ensures that these plans remain viable. Criteria for making changes to service continuity and incident management plans may include:

• changes to services or how those services are delivered
• relationship changes
• regulatory changes
• weaknesses or gaps identified as a result of testing or an activation of the plan

[IMC:GG2.GP8] Monitor and Control the Process

Periodic reviews of the incident management and control process are needed to ensure that

• the process is known and accessible
• events and incidents are identified, reported, and addressed on a timely basis
• events and incidents are logged and closed
• events are properly triaged and analyzed for root causes
• incidents are properly declared
• incidents are properly escalated to designated stakeholders
• incidents are communicated appropriately to stakeholders at a level commensurate with their involvement
• event and incident status reports are provided to appropriate stakeholders in a timely manner
• post-incident reviews are performed to improve the process
• actions requiring management involvement are elevated in a timely manner
• the performance of process activities is being monitored and regularly reported

Additional References

NIST Special Publication 800-34, “Contingency Planning for Federal Information Systems,” Chapter 3.6 Plan Maintenance.

To be effective, the plan must be maintained in a ready state that accurately reflects system requirements, procedures, organizational structure, and policies. As identified as part of RMF Step 6 (Continuous Monitoring), a continuous monitoring process can provide organizations with an effective tool for plan maintenance, producing ongoing updates to security plans, security assessment reports, and plans of action and milestone documents.

As a general rule, the plan should be reviewed for accuracy and completeness at an organization-defined frequency or whenever significant changes occur to any element of the plan. Certain elements, such as contact lists, will require more frequent reviews. The plans for moderate- or high-impact systems should be reviewed more often.

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations.”

NIST CSF References: ID.SC-2, ID.SC-3

CERT-RMM References

[EXD:SG4.SP1] Monitor External Entity Performance

The performance of external entities is monitored to ensure against specifications, including:

• controls and control environments
• financial condition and management practices of the external entity
• service continuity and incident management plans
• compliance practices and performance

[CTRL:SG4.SP1] Assess Controls

Assessing the control system at external entities is an ongoing activity that allows the acquirer to measure the effectiveness of controls across resilience activities. For example, through monitoring and ongoing measurement and analysis, the acquirer can determine whether controls at external entities are satisfying control objectives, strategies for protecting and sustaining services and assets, and resilience requirements. These activities can also ascertain if controls for resilience activities are effective and producing the intended results. Monitoring and measurement are two ways that the acquirer collects necessary data (and invokes a vital feedback loop) to know how well controls are performing in support of the operational resilience of high value services.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-12(11) Supply Chain Protection | Penetration Testing / Analysis of Elements, Processes, and Actors.

The organization employs one or more of the following: organizational analysis, independent third-party analysis, organizational penetration testing, independent third-party penetration testing of organization-defined supply chain elements, processes, and actors associated with the information system, system component, or information system service.

Supplemental Guidance: This control enhancement addresses analysis and/or testing of the supply chain, not just delivered items. Supply chain elements are information technology products or product components that contain programmable logic and that are critically important to information system functions. Supply chain processes include, for example: (i) hardware, software, and firmware development processes; (ii) shipping/ handling procedures; (iii) personnel and physical security programs; (iv) configuration management tools/measures to maintain provenance; or (v) any other programs, processes, or procedures associated with the production/distribution of supply chain elements. Supply chain actors are individuals with specific roles and responsibilities in the supply chain. The evidence generated during analyses and testing of supply chain elements, processes, and actors is documented and used to inform organizational risk management activities and decisions.

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations, ICT SCRM Controls,” 43-49.

NIST CSF References: ID.SC-4

CERT-RMM Reference

[EXD:SG4.SP1] Monitor External Entity Performance

The performance of external entities is monitored to ensure against specifications, including:

• controls and control environments
• financial condition and management practices of the external entity
• service continuity and incident management plans compliance practices and performance

[CTRL:SG4.SP1] Assess Controls

Assessing the control system at external entities is an ongoing activity that allows the acquirer to measure the effectiveness of controls across resilience activities. For example, through monitoring and ongoing measurement and analysis, the acquirer can determine whether controls at external entities are satisfying control objectives, strategies for protecting and sustaining services and assets, and resilience requirements. These activities can also ascertain if controls for resilience activities are effective and producing the intended results. Monitoring and measurement are two ways that the acquirer collects necessary data (and invokes a vital feedback loop) to know how well controls are performing in support of the operational resilience of high-value services.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” 4.2.7 Integrator - Verification and Validation Requirements.

Demonstrate that a mix of personnel, physical, and logical access controls are implemented which provide a level of protection commensurate with the sensitivity/criticality of the services provided or the elements procured.

1. Perform technical and procedural audits of mechanisms used to shield information related to elements, including uses, requirements, and metadata.
2. Employ Red Team approaches to identify potential pathways or opportunities for adversaries to exploit deficits or weaknesses in supply chain processes that would result in the exposure of the element or associated information including uses of element.
3. Assess the effectiveness of alternative configurations in protecting access of elements, processes, systems, and information for the purposes of confidentiality, integrity, and availability.
4. Test internal access controls for the ability to detect anomalous behavior and facilitate timely intervention to prevent or reduce adverse consequences.

NIST Special Publication 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations,” Section 3 ICT SCRM Controls, 43-49.

NIST CSF References: ID.SC-1, ID.SC-2, ID.SC-3, ID.SC-4

CERT-RMM Reference

[MON:SG1.SP2] Identify Stakeholders

Identify stakeholders of the monitoring process. The list should include internal and external stakeholders and should be seeded by examining operational resilience management processes and their organizational owners. Stakeholders of the organization’s monitoring processes are those internal and external people, entities, or agencies that require information about the operational resilience management processes for which they have responsibility and for which they must achieve resilience goals, objectives, and obligations.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” 2.2 Foundational Practices.

Assign roles and responsibilities to specific individuals, including who has the required authority to take action, who has accountability for an action or result, and who should be consulted and/or informed.

Ensure information system security, acquisition personnel, legal counsel, and other appropriate advisors and stakeholders are participating in decision making from system concept definition/review and are involved in, or approve of, each milestone decision through the entire system life cycle for federal systems.

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” Section 2.1 Organization-wide View of ISCM.

NIST CSF References: ID.AM-6, ID.RA-2, PR.AT-5

CERT-RMM Reference

[MON:SG2.SP2] Establish Collection Standards and Guidelines

Review, refine, and develop monitoring operating procedures. Detailed processes, standard operating procedures, or work instructions may be created during monitoring infrastructure implementation, but they will need to be regularly reviewed, tailored, and possibly supplemented to meet ongoing monitoring needs.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SI-4 Information System Monitoring.

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” 19-26.

NIST CSF References: ID.RA-2, ID.RA-3

CERT-RMM Reference

[MON:SG1.SP3] Establish Monitoring Requirements

The scope of the monitoring activity determines how extensive the organization's processes must be and may be a deciding factor in how the organization develops and implements appropriate infrastructure to meet the requirements of stakeholders. The scope is a direct reflection of the needs and requirements of stakeholders.

The requirements of stakeholders must clearly establish the information and data that they need on a regular basis to manage, measure, direct, control, and improve processes for which they have responsibility.

NIST Reference

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, Section 2.5 External Service Providers.

NIST CSF References: ID.RA-3, PR.IP-8, RS.CO-5

CERT-RMM References

[MON:SG2.SP2] Establish Collection Standards and Guidelines

Collected and recorded information is distributed to appropriate stakeholders. The continuous and effective management of operational resilience is highly dependent on information collected in the monitoring process. Some of the key objectives of monitoring and information distribution are

• identifying, preventing, and responding to threats and disruptive events
• determining the effectiveness of strategies to protect and sustain assets and services
• determining the effectiveness of resilience management processes
• improving resilience management processes

To meet these objectives, monitoring information must be available for use when needed by stakeholders, internally and externally. Thus, the acquirer must establish viable distribution methods and channels to move collected information to stakeholders as requested in a reliable and consistent manner.

[COMM:SG3.SP2] Establish and maintain communications infrastructure

Communicate threat information to key internal and external stakeholders. Implement and manage the communications infrastructure.

Additional References

NISTIR 7622, “Notional Supply Chain Risk Management Practices for Federal Information Systems,” 2.1 Challenges.

Furthermore, acquirer, integrator, and supplier organizations generally implement quality and security through two separate enterprise operational organizations. Supply chain quality and security vulnerabilities are likely to be addressed through these separate organizations. Whether addressing intentional or unintentional vulnerabilities and related mitigations, cross-communication between these two enterprise organizations is required to holistically approach ICT SCRM.

NIST Special Publication 800-30, “Risk Management Guide for Information Technology Systems,” 14-15.

NIST CSF References: ID.RA-2, PR.IP-8, RS.CO-5

CERT-RMM References

[MON:SG2.SP1] Establish and Maintain Monitoring Infrastructure

Effective operational risk management and situational awareness requires organizations to establish a monitoring infrastructure commensurate with meeting monitoring requirements. Monitoring is a data-collection-intensive activity that is often dependent on supporting services and infrastructure that span the organization and often extend outside the organization. Some of the key reasons for leveraging external resources (e.g., umbrella or industry groups, regulatory agencies, cyber-threat assessment vendors) include

• organizations may not have a core competency in collecting information
• the scope and breadth of the threat landscape make it too complex and costly to collect and process that information
• leveraging organizations whose primary mission is the collection, analysis, and dissemination of threat information is more effective and efficient

[MON:GG2.GP7] Identify and Involve Relevant Stakeholders

These are examples of stakeholders of the monitoring process (refer to MON:SG1.SP2):

• boards of directors and governors
• higher level and other managers
• service owners and asset owners and custodians
• information technology staff, such as system administrators and CSIRT teams
• business partners, vendors, and outsourcers
• police and security guards
• public agencies
• regulatory bodies
• internal and external auditors
• owners of operational resilience management processes
• staff identified as being associated with each process requirement, program, and distribution channel
• staff identified as being associated with each external entity that is collecting and distributing monitoring data

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, SA-12(8) Supply Chain Protection| Use of All- Source Intelligence.

The organization uses all-source intelligence analysis of suppliers and potential suppliers of the information system, system component, or information system service.

Supplemental Guidance: All-source intelligence analysis is employed by organizations to inform engineering, acquisition, and risk management decisions. All-source intelligence consists of intelligence products and/or organizations and activities that incorporate all sources of information, most frequently including human intelligence, imagery intelligence, measurement and signature intelligence, signals intelligence, and open-source data in the production of finished intelligence. Where available, such information is used to analyze the risk of both intentional and unintentional vulnerabilities from development, manufacturing, and delivery processes, people, and the environment. This review is performed on suppliers at multiple tiers in the supply chain sufficient to manage risks.

Related control: SA-15

NIST Special Publication 800-137, “Information Security Continuous Monitoring for Federal Information Systems and Organizations.”

NISTIR 7756, “CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Model (Second Draft).”

NIST CSF References: ID.RA-2, RS.CO-5

CERT-RMM References

[MON:SG1.SP3] Establish Monitoring Requirements

The scope of the monitoring activity determines how extensive the organization's processes must be and may be a deciding factor in how the organization develops and implements appropriate infrastructure to meet the requirements of stakeholders. The scope is a direct reflection of the needs and requirements of stakeholders. The requirements of stakeholders must clearly establish the information and data that they need on a regular basis to manage, measure, direct, control, and improve processes for which they have responsibility.

Stakeholders are those internal and external people, entities, or agencies that require information about the operational resilience management processes for which they have responsibility and for which they must achieve resilience goals, objectives, or obligations. Relevant stakeholders may include the CEO and CIO, and in the case of external dependencies, may extend to legal counsel and other relationship managers.

[MON:SG2.SP4] Distribute Information

The continuous and effective management of operational resilience is highly dependent on information collected in the monitoring process. This information is useful for

• identifying, preventing, and responding to disruptive events
• determining the effectiveness of strategies to protect and sustain assets and services
• determining the effectiveness of operational resilience management processes
• improving operational resilience management processes when necessary

To meet these objectives, monitoring information must be available for use when needed by stakeholders. Thus, the organization must establish viable distribution methods and channels to move collected information to stakeholders as-requested in a reliable and consistent manner.

Additional References

NIST Special Publication 800-53 Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”, 2.1 Multitiered Risk Management.

. . . To integrate the risk management process throughout the organization and more effectively address mission/business concerns, a three-tiered approach is employed that addresses risk at the: (i) organization level; (ii) mission/business process level; and (iii) information system level. The risk management process is carried out across the three tiers with the overall objective of continuous improvement in the organization's risk-related activities and effective inter-tier and intra-tier communication among all stakeholders having a shared interest in the mission/business success of the organization.

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” Section 3.3 Implement a Continuous Monitoring Program.

NIST CSF References: PR.IP-8, RS.CO-5

CERT-RMM Reference

Consider developing a plan for performing External Dependencies Management. A plan is developed to ensure that the acquirer and its staff know how external dependencies will be managed across the entire lifecycle of relationships. External dependencies exist when external entities have defined obligations or relationships with assets or services that the acquirer depends on to support the critical service.

Examples include external entities that provide, operate, control, have access to, own, or have other responsibilities with respect to key assets.

The plan should address the resilience specifications for the critical service or the product being provided. The EDM plan should detail how core goals relating to EDM will be performed - for example evaluating suppliers, entering into formal agreements, monitoring changes at external entities, and prioritizing dependencies. The EDM plan will normally also detail the other resilience and security domains that are relevant to EDM at the acquirer. These may include, for example, risk management, incident management, service continuity, or change management. This is important so that resilience processes across the acquirer will adequately support EDM according to consistent requirements and priorities.

In practice, many of the required actions to manage external dependencies may be documented in other plans or documents (for example vendor selection and contracting procedures). The purpose of an EDM plan is not to duplicate or repeat material in other plans or documentation, but rather to clarify and harmonize the roles and responsibilities of staff and processes across the acquirer. For example, the acquirer's service continuity plan may include actions involving suppliers in the event of a natural disaster.

The EDM plan, on the other hand, may detail roles, responsibilities, and processes to ensure that continuity plans are updated based on relevant changes, for example contractual changes that may affect service continuity. The plan may detail how different functions or departments will coordinate their efforts to support EDM.

Plans should explain:

• who performs EDM practices
• key stakeholders
• when and how often they are performed, and
• the key processes involve in EDM

Typical items addressed in an EDM plan may include:

• identifying and prioritizing external dependencies
• associating external dependencies with services and assets
• managing operational risks resulting from external dependencies
• evaluating and selecting external entities
• formalizing and enforcing agreements with external entities, including changing provisions
• terminations of relationships with external entities
• change management with external entities
• integrating external dependencies into incident management and service continuity planning and exercising

Sub practices:

• Document the plan
• Document the process description
• Review the plan with relevant stakeholders and obtain their agreement
• Revise the plan as necessary

CERT-RMM Reference

Consider developing policies for external dependencies management. Policy consists of high-level statements by organizational leadership concerning external dependencies management. The purpose of policy is to establish and maintain governance over the planning and performance of external dependencies management. Policy will typically address:

• responsibility, authority, and ownership for performing activities


• the importance of external dependencies management


• the acquirer's approach to its critical services and their prioritization


• methods for measuring adherence to policy, granting exceptions, and identifying policy violations


• consequences for non-compliance with policy


• the acquirer's approach to selecting suppliers and external entities


• the acquirer's approach to risk management as it pertains to external dependencies


• enterprise requirements or policies to which external entities are expected to adhere


• monitoring the performance of external entities


• issue escalation and dispute resolution


• applying corrective action to relationships with external entities as specified in formal agreements


• terminating relationships with external entities as specified in formal agreements

CERT-RMM Reference

Consider including process descriptions for EDM in policy or plan documents. Process descriptions document the series of actions or specific steps that are necessary to perform external dependencies management activities in a repeatable, predictable manner.

Examples may include:

• the process to form supplier relationships, for example the steps (“gates”) and approval authorities required for new relationships


• the actions required to purchase or invest in new technology


• processes to ensure that external entity concerns are included in risk management. For example, these may include a process to ensure that supplier performance problems are entered into risk registers or other risk monitoring tools.


• the process to identify external dependencies, for example processes involving checking internal financial statements to identify supplier relationships outside the formal relationship management program.


• the process to make changes to plans that involve external dependencies management, for example the service continuity, risk management, or incident management plans


• the process to ensure that requirements for infrastructure providers and governmental services are managed. For example, these processes may focus on advising the corporate staff who interface with infrastructure and governmental authorities about changes and threats to the critical service.


• the process to transition supplier relationships including, for example, the input of technical staff or critical service business owners at the acquirer.


• the process to manage external entity access to the acquirer, for example the process to remove access when contractor staff are terminated or change staff positions

CERT-RMM Reference

Consider identifying stakeholders of the EDM process and engaging them to ensure they are aware of their roles. Examples include:

• internal and external owners and custodians of organizational assets
• internal and external service owners
• organizational unit and line of business managers responsible for high-value assets and the services they support
• staff responsible for managing operational risk
• staff responsible for establishing, implementing, and maintaining an internal control system for organizational assets
• staff required to develop, test, implement, and execute service continuity plans that involve external dependencies
• acquisition and procurement staff
• internal and external auditors

CERT-RMM Reference

Consider developing standards and guidelines for external dependencies management. Examples include:

• criteria for prioritizing external dependencies
• templates that define the information required to identify, track and manage external dependencies in databases or information repositories
• the guidelines and standards required to make risk statements and impact valuations
• agreement templates, including enterprise specifications that apply to external entities
• standard RFPs, including applicable requirements
• criteria for selecting external entities
• performance-monitoring report standards and templates
• inspection reports on deliverables
• corrective-action report standards and examples

CERT-RMM Reference

Consider implementing management oversight of EDM processes. Oversight may involve the following manager activities:

• defining roles and responsibilities for processes in the EDM plan
• requiring reporting from staff concerning EDM status and issues
• developing policy that requires relevant staff to participate in EDM processes
• including EDM responsibilities in staff performance management goals and objectives, tracking progress against goals, and counseling or disciplining staff based on performance

CERT-RMM Reference

Consider managing risks to EDM practices and processes. Examples of risks include:

• the acquirer's incorrect prioritization of external dependencies, related to insufficient standards or process definition
• the risk of variability or inaccuracies in risk statements or valuations relating to external dependencies
• imprecise supplier selection criteria and the risk of improper influence of acquirer staff
• enterprise specifications and baseline requirements for contracts, and the risk that regulatory compliance requirements may change
• risks related to a lack of skilled staff or knowledge, for example the risk that staff are unaware that specific proprietary software may include open source segments or modules that can introduce unforeseen vulnerabilities
• the risk that centrally (or corporate) managed relationships with infrastructure or governmental service providers may not adequately account for the critical service's resilience requirements

CERT-RMM Reference

Consider ensuring that responsible staff are trained in skills required in external dependencies management. These are examples of skills required:

• identifying and prioritizing external dependencies
• elicitation of resilience specifications to be reflected in RFPs and agreements with external entities
• evaluating and selecting external entities
• negotiating agreements with external entities
• knowledge of tools, techniques, and methods that can be used to identify, analyze, mitigate, and monitor operational risks
• managing relationships with external entities
• monitoring the performance of external entities, including the inspection of deliverables and knowing when corrective actions are required
• technical skills to evaluate technology that the acquirer is considering procuring

CERT-RMM Reference

Consider ensuring that external dependencies management activities are adequately funded. Funding the process should extend beyond the initial development of the activities, and include maintenance and refresh.

CERT-RMM Reference

Consider measuring and periodically reviewing EDM processes to ensure they are effective and producing intended results. Example measures may include:

• percentage of external entities that have undergone some form of assessment, risk assessment, and audit
• Count or percentage of suppliers or external entities in certain categories, for example:
  • by agreement type (formal contract with and without SLA, memorandum of agreement, purchase order, licensing agreement, and other, including no type of agreement)
  • by number or type of unforeseen or disruptive agreement changes
  • by performance problems
  • by problems relating to responsiveness or timeliness involving EDM practices, for example participation in service continuity planning or change management boards
  • located in less suitable geographic or political regions (for example characterized by political instability or physical security problems)
  • count of suppliers with which the acquirer has open litigation involving the critical service
  • by supplier adherence or compliance with independent standards
• number of supplier relationships terminated for performance failures
• percentage or absolute count of suppliers that failed to perform as expected during a disruptive event
• count of suppliers that are single points of failure
• percentage of suppliers whose deliverables have failed to pass inspection
• changes or variability in resource needs to support the process
• effectiveness of other acquirer business processes that support EDM (risk management, Human Resources, accounting, etc.)

CERT-RMM Reference

Consider objectively evaluating adherence of the EDM process against its process description, standards, and procedures, and address non-compliance.

Evaluating adherence to the EDM process may be done by analyzing measures such as:

• percentage of external dependencies without designated organizational owners
• percentage of external entities that have undergone some form of assessment, risk assessment, and audit compared to EDM plans and policies
• count of supplier relationships formed outside the EDM process
• percentage of external dependency records or database entries with old or incomplete information

CERT-RMM Reference

Consider ensuring that the acquirer reviews the activities, status, and results of the external dependencies management process with higher-level managers and resolves issues.

Normally, effective review with higher level (or board level) management requires ongoing discussion and identification of effectiveness and cost measures that are important for these stakeholders. These should form the basis for measurements and reporting involving effectiveness and process adherence.

CERT-RMM Reference

Consider identifying standard, defined EDM processes for the acquirer enterprise. This includes:

• selecting - from the processes used by business units, divisions, or industry peers - the EDM processes that best meet the needs of the enterprise
• ensuring that the enterprise's business, policy, and process objectives are appropriately addressed in this standard, defined process
• documenting the defined process
• revising the description of the standard, defined enterprise process as necessary

CERT-RMM Reference

Consider tailoring the enterprise guidelines for the enterprise's defined EDM processes. The purpose of tailoring guidelines is to help individual operating units derive EDM practices that best suit their unique operating circumstances and requirements - while allowing enterprise management to realize predictability, confidence in, and efficiencies in EDM capability across the enterprise.

Tailoring guidelines involve guidance concerning organizationally acceptable refinements and deviations from the defined process. Guidelines may involve any EDM goal or domain. The guidelines may address situations such as:

• Differences in the mission criticality or importance of critical services across business units


• Differences in EDM activities dictated by legal differences in the local jurisdiction of a separate business unit. These may involve contract, labor, or privacy law among others.


• Differences related to the availability of suitable suppliers in different regions


• Differences in the customer base of different business units. For example an enterprise may issue guidelines to business units that serve private customers, as well as other business units that serve an exclusively governmental customer base. The relevant guidelines would explain how to tailor standard enterprise process to meet the compliance or process requirements of each customer type.

CERT-RMM Reference

Consider collecting external dependencies management work products, measures, measurement results, and improvement information from business units to support future use and improvement of the enterprise's processes.